January 2024 - Linux-stable-mirror

[PATCH 5.10.y 0/1] bpf: fix warning ftrace_verify_code

by kovalev＠altlinux.org

Syzkaller hit 'WARNING in ftrace_verify_code' bug. This bug is not a vulnerability and is reproduced only when running with root privileges on stable 5.10 kernel. journalctl -k (v5.10.206): ... bpfilter: Loaded bpfilter_umh pid 2732 Started bpfilter ------------[ cut here ]------------ ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4107 at arch/x86/kernel/ftrace.c:97 ftrace_verify_code+0x3e/0x80 WARNING: CPU: 1 PID: 4107 at arch/x86/kernel/ftrace.c:97 ftrace_verify_code+0x3e/0x80 Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter bridge stp llc qrtr bnep hid_generic usbhid uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common btusb btrtl btbcm btintel videodev bluetooth mc ecdh_generic ecc nls_utf8 nls_cp866 vfat fat coretemp hwmon x86_pkg_temp_thermal intel_powerclamp mei_hdcp kvm_intel kvm rtsx_pci_sdmmc mmc_core irqbypass crct10dif_pclmul wmi_bmof crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci mei_me ucsi_acpi ideapad_laptop cryptd xhci_pci_renesas glue_helper pcspkr typec_ucsi tiny_power_button rtsx_pci sparse_keymap xhci_hcd mei thermal typec wmi i2c_hid button fan rfkill hid acpi_pad intel_pmc_core battery video ac sch_fq_codel vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) vboxvideo Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter bridge stp llc qrtr bnep hid_generic usbhid uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common btusb btrtl btbcm btintel videodev bluetooth mc ecdh_generic ecc nls_utf8 nls_cp866 vfat fat coretemp hwmon x86_pkg_temp_thermal intel_powerclamp mei_hdcp kvm_intel kvm rtsx_pci_sdmmc mmc_core irqbypass crct10dif_pclmul wmi_bmof crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci mei_me ucsi_acpi ideapad_laptop cryptd xhci_pci_renesas glue_helper pcspkr typec_ucsi tiny_power_button rtsx_pci sparse_keymap xhci_hcd mei thermal typec wmi i2c_hid button fan rfkill hid acpi_pad intel_pmc_core battery video ac sch_fq_codel vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) vboxvideo drm_vram_helper drm_ttm_helper ttm drm_kms_helper cec rc_core vboxsf vboxguest snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_seq_device snd_timer snd soundcore drm msr fuse dm_mod efi_pstore efivarfs ip_tables x_tables autofs4 evdev input_leds serio_raw drm_vram_helper drm_ttm_helper ttm drm_kms_helper cec rc_core vboxsf vboxguest snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_seq_device snd_timer snd soundcore drm msr fuse dm_mod efi_pstore efivarfs ip_tables x_tables autofs4 evdev input_leds serio_raw CPU: 1 PID: 4107 Comm: repro5 Tainted: G OE 5.10.206-std-def-alt1 #1 CPU: 1 PID: 4107 Comm: repro5 Tainted: G OE 5.10.206-std-def-alt1 #1 Hardware name: LENOVO 82X8/LNVNB161216, BIOS LTCN30WW 11/08/2023 Hardware name: LENOVO 82X8/LNVNB161216, BIOS LTCN30WW 11/08/2023 RIP: 0010:ftrace_verify_code+0x3e/0x80 RIP: 0010:ftrace_verify_code+0x3e/0x80 Code: 25 28 00 00 00 48 89 44 24 08 31 c0 48 8d 7c 24 03 e8 56 f9 1b 00 48 85 c0 75 3e 8b 03 39 44 24 03 74 28 48 89 1d e2 1d 05 03 <0f> 0b b8 ea ff ff ff 48 8b 4c 24 08 65 48 2b 0c 25 28 00 00 00 75 Code: 25 28 00 00 00 48 89 44 24 08 31 c0 48 8d 7c 24 03 e8 56 f9 1b 00 48 85 c0 75 3e 8b 03 39 44 24 03 74 28 48 89 1d e2 1d 05 03 <0f> 0b b8 ea ff ff ff 48 8b 4c 24 08 65 48 2b 0c 25 28 00 00 00 75 RSP: 0018:ffffc90003aa7c88 EFLAGS: 00010212 RSP: 0018:ffffc90003aa7c88 EFLAGS: 00010212 RAX: 0000000000441f0f RBX: ffffffff82005684 RCX: 0000000000000010 RAX: 0000000000441f0f RBX: ffffffff82005684 RCX: 0000000000000010 RDX: 000000000f9dbb1f RSI: 0000000000000005 RDI: ffffffff8183d240 RDX: 000000000f9dbb1f RSI: 0000000000000005 RDI: ffffffff8183d240 RBP: ffff8881000607a0 R08: 0000000000000001 R09: 0000000000000000 RBP: ffff8881000607a0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff840b9f40 R14: ffffffff82005684 R15: ffffffff82a6a760 R13: ffffffff840b9f40 R14: ffffffff82005684 R15: ffffffff82a6a760 FS: 00007f671d1c2640(0000) GS:ffff8882a7840000(0000) knlGS:0000000000000000 FS: 00007f671d1c2640(0000) GS:ffff8882a7840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007efd44003490 CR3: 000000013e3f2000 CR4: 0000000000750ee0 CR2: 00007efd44003490 CR3: 000000013e3f2000 CR4: 0000000000750ee0 PKRU: 55555554 PKRU: 55555554 Call Trace: Call Trace: ? __warn+0x80/0x100 ? __warn+0x80/0x100 ? ftrace_verify_code+0x3e/0x80 ? ftrace_verify_code+0x3e/0x80 ? report_bug+0x9e/0xc0 ? report_bug+0x9e/0xc0 ? handle_bug+0x32/0xa0 ? handle_bug+0x32/0xa0 ? exc_invalid_op+0x14/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x12/0x20 ? asm_exc_invalid_op+0x12/0x20 ? sk_lookup_convert_ctx_access+0x280/0x280 ? sk_lookup_convert_ctx_access+0x280/0x280 ? ftrace_verify_code+0x3e/0x80 ? ftrace_verify_code+0x3e/0x80 ? ftrace_verify_code+0x2a/0x80 ? ftrace_verify_code+0x2a/0x80 ftrace_replace_code+0xa6/0x190 ftrace_replace_code+0xa6/0x190 ftrace_modify_all_code+0xd8/0x170 ftrace_modify_all_code+0xd8/0x170 ftrace_run_update_code+0x13/0x70 ftrace_run_update_code+0x13/0x70 ftrace_startup.part.0+0xe9/0x160 ftrace_startup.part.0+0xe9/0x160 register_ftrace_function+0x52/0x90 register_ftrace_function+0x52/0x90 perf_trace_event_init+0x60/0x2b0 perf_trace_event_init+0x60/0x2b0 perf_trace_init+0x69/0xa0 perf_trace_init+0x69/0xa0 perf_tp_event_init+0x1b/0x50 perf_tp_event_init+0x1b/0x50 perf_try_init_event+0x42/0x130 perf_try_init_event+0x42/0x130 perf_event_alloc+0x5e3/0xdf0 perf_event_alloc+0x5e3/0xdf0 ? __alloc_fd+0x44/0x170 ? __alloc_fd+0x44/0x170 __do_sys_perf_event_open+0x1cd/0xec0 __do_sys_perf_event_open+0x1cd/0xec0 do_syscall_64+0x30/0x40 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x62/0xc7 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f671d2c0d49 RIP: 0033:0x7f671d2c0d49 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 73 01 c3 48 8b 0d ef 70 0d 00 f7 d8 64 89 01 48 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 73 01 c3 48 8b 0d ef 70 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007f671d1c1df8 EFLAGS: 00000246 ORIG_RAX: 000000000000012a RSP: 002b:00007f671d1c1df8 EFLAGS: 00000246 ORIG_RAX: 000000000000012a RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f671d2c0d49 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f671d2c0d49 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0 RBP: 00007f671d1c1e20 R08: 0000000000000000 R09: 0000000000000000 RBP: 00007f671d1c1e20 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd562f62de R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd562f62de R13: 00007ffd562f62df R14: 0000000000000000 R15: 00007f671d1c2640 R13: 00007ffd562f62df R14: 0000000000000000 R15: 00007f671d1c2640 ---[ end trace 74a81e537b634ec5 ]--- ---[ end trace 74a81e537b634ec5 ]--- ------------[ ftrace bug ]------------ ------------[ ftrace bug ]------------ ftrace failed to modify ftrace failed to modify [<ffffffff8183d240>] bpf_dispatcher_xdp_func+0x0/0x10 [<ffffffff8183d240>] bpf_dispatcher_xdp_func+0x0/0x10 actual: ffffffe9:ffffffbb:ffffff9d:0f:1f actual: ffffffe9:ffffffbb:ffffff9d:0f:1f expected: 0f:1f:44:00:00 expected: 0f:1f:44:00:00 Setting ftrace call site to call ftrace function Setting ftrace call site to call ftrace function ftrace record flags: 10000001 ftrace record flags: 10000001 (1) (1) expected tramp: ffffffff81068ac0 ------------[ cut here ]------------ ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4107 at kernel/trace/ftrace.c:2075 ftrace_bug+0x22c/0x256 WARNING: CPU: 1 PID: 4107 at kernel/trace/ftrace.c:2075 ftrace_bug+0x22c/0x256 Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter bridge stp llc qrtr bnep hid_generic usbhid uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common btusb btrtl btbcm btintel videodev bluetooth mc ecdh_generic ecc nls_utf8 nls_cp866 vfat fat coretemp hwmon x86_pkg_temp_thermal intel_powerclamp mei_hdcp kvm_intel kvm rtsx_pci_sdmmc mmc_core irqbypass crct10dif_pclmul wmi_bmof crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci mei_me ucsi_acpi ideapad_laptop cryptd xhci_pci_renesas glue_helper pcspkr typec_ucsi tiny_power_button rtsx_pci sparse_keymap xhci_hcd mei thermal typec wmi i2c_hid button fan rfkill hid acpi_pad intel_pmc_core battery video ac sch_fq_codel vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) vboxvideo Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter bridge stp llc qrtr bnep hid_generic usbhid uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common btusb btrtl btbcm btintel videodev bluetooth mc ecdh_generic ecc nls_utf8 nls_cp866 vfat fat coretemp hwmon x86_pkg_temp_thermal intel_powerclamp mei_hdcp kvm_intel kvm rtsx_pci_sdmmc mmc_core irqbypass crct10dif_pclmul wmi_bmof crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd xhci_pci mei_me ucsi_acpi ideapad_laptop cryptd xhci_pci_renesas glue_helper pcspkr typec_ucsi tiny_power_button rtsx_pci sparse_keymap xhci_hcd mei thermal typec wmi i2c_hid button fan rfkill hid acpi_pad intel_pmc_core battery video ac sch_fq_codel vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) vboxvideo drm_vram_helper drm_ttm_helper ttm drm_kms_helper cec rc_core vboxsf vboxguest snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_seq_device snd_timer snd soundcore drm msr fuse dm_mod efi_pstore efivarfs ip_tables x_tables autofs4 evdev input_leds serio_raw drm_vram_helper drm_ttm_helper ttm drm_kms_helper cec rc_core vboxsf vboxguest snd_seq_midi snd_seq_midi_event snd_seq snd_rawmidi snd_seq_device snd_timer snd soundcore drm msr fuse dm_mod efi_pstore efivarfs ip_tables x_tables autofs4 evdev input_leds serio_raw CPU: 1 PID: 4107 Comm: repro5 Tainted: G W OE 5.10.206-std-def-alt1 #1 CPU: 1 PID: 4107 Comm: repro5 Tainted: G W OE 5.10.206-std-def-alt1 #1 Hardware name: LENOVO 82X8/LNVNB161216, BIOS LTCN30WW 11/08/2023 Hardware name: LENOVO 82X8/LNVNB161216, BIOS LTCN30WW 11/08/2023 RIP: 0010:ftrace_bug+0x22c/0x256 RIP: 0010:ftrace_bug+0x22c/0x256 Code: ff 84 c0 74 d0 eb b4 48 c7 c7 36 4b 30 82 e8 0b c5 ff ff 48 89 ef e8 2a df 7a ff 48 c7 c7 47 4b 30 82 48 89 c6 e8 f4 c4 ff ff <0f> 0b c7 05 0f a5 2c 01 01 00 00 00 5b c7 05 14 a5 2c 01 00 00 00 Code: ff 84 c0 74 d0 eb b4 48 c7 c7 36 4b 30 82 e8 0b c5 ff ff 48 89 ef e8 2a df 7a ff 48 c7 c7 47 4b 30 82 48 89 c6 e8 f4 c4 ff ff <0f> 0b c7 05 0f a5 2c 01 01 00 00 00 5b c7 05 14 a5 2c 01 00 00 00 RSP: 0018:ffffc90003aa7c88 EFLAGS: 00010246 RSP: 0018:ffffc90003aa7c88 EFLAGS: 00010246 RAX: 0000000000000022 RBX: 00000000ffffffea RCX: ffff8882a7860808 RAX: 0000000000000022 RBX: 00000000ffffffea RCX: ffff8882a7860808 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8882a7860800 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8882a7860800 RBP: ffff8881000607a0 R08: 0000000000000000 R09: ffffc90003aa7ac8 RBP: ffff8881000607a0 R08: 0000000000000000 R09: ffffc90003aa7ac8 R10: ffffc90003aa7ac0 R11: ffffffff82ae22e8 R12: ffffffff8183d240 R10: ffffc90003aa7ac0 R11: ffffffff82ae22e8 R12: ffffffff8183d240 R13: ffffffff840b9f40 R14: ffffffff82005684 R15: ffffffff82a6a760 R13: ffffffff840b9f40 R14: ffffffff82005684 R15: ffffffff82a6a760 FS: 00007f671d1c2640(0000) GS:ffff8882a7840000(0000) knlGS:0000000000000000 FS: 00007f671d1c2640(0000) GS:ffff8882a7840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007efd44003490 CR3: 000000013e3f2000 CR4: 0000000000750ee0 CR2: 00007efd44003490 CR3: 000000013e3f2000 CR4: 0000000000750ee0 PKRU: 55555554 PKRU: 55555554 Call Trace: Call Trace: ? __warn+0x80/0x100 ? __warn+0x80/0x100 ? ftrace_bug+0x22c/0x256 ? ftrace_bug+0x22c/0x256 ? report_bug+0x9e/0xc0 ? report_bug+0x9e/0xc0 ? handle_bug+0x32/0xa0 ? handle_bug+0x32/0xa0 ? exc_invalid_op+0x14/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x12/0x20 ? asm_exc_invalid_op+0x12/0x20 ? sk_lookup_convert_ctx_access+0x280/0x280 ? sk_lookup_convert_ctx_access+0x280/0x280 ? ftrace_bug+0x22c/0x256 ? ftrace_bug+0x22c/0x256 ? ftrace_bug+0x22c/0x256 ? ftrace_bug+0x22c/0x256 ftrace_replace_code+0xbb/0x190 ftrace_replace_code+0xbb/0x190 ftrace_modify_all_code+0xd8/0x170 ftrace_modify_all_code+0xd8/0x170 ftrace_run_update_code+0x13/0x70 ftrace_run_update_code+0x13/0x70 ftrace_startup.part.0+0xe9/0x160 ftrace_startup.part.0+0xe9/0x160 register_ftrace_function+0x52/0x90 register_ftrace_function+0x52/0x90 perf_trace_event_init+0x60/0x2b0 perf_trace_event_init+0x60/0x2b0 perf_trace_init+0x69/0xa0 perf_trace_init+0x69/0xa0 perf_tp_event_init+0x1b/0x50 perf_tp_event_init+0x1b/0x50 perf_try_init_event+0x42/0x130 perf_try_init_event+0x42/0x130 perf_event_alloc+0x5e3/0xdf0 perf_event_alloc+0x5e3/0xdf0 ? __alloc_fd+0x44/0x170 ? __alloc_fd+0x44/0x170 __do_sys_perf_event_open+0x1cd/0xec0 __do_sys_perf_event_open+0x1cd/0xec0 do_syscall_64+0x30/0x40 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x62/0xc7 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f671d2c0d49 RIP: 0033:0x7f671d2c0d49 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 73 01 c3 48 8b 0d ef 70 0d 00 f7 d8 64 89 01 48 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 73 01 c3 48 8b 0d ef 70 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007f671d1c1df8 EFLAGS: 00000246 ORIG_RAX: 000000000000012a RSP: 002b:00007f671d1c1df8 EFLAGS: 00000246 ORIG_RAX: 000000000000012a RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f671d2c0d49 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f671d2c0d49 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200000c0 RBP: 00007f671d1c1e20 R08: 0000000000000000 R09: 0000000000000000 RBP: 00007f671d1c1e20 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd562f62de R10: 00000000ffffffff R11: 0000000000000246 R12: 00007ffd562f62de R13: 00007ffd562f62df R14: 0000000000000000 R15: 00007f671d1c2640 R13: 00007ffd562f62df R14: 0000000000000000 R15: 00007f671d1c2640 ---[ end trace 74a81e537b634ec6 ]--- ---[ end trace 74a81e537b634ec6 ]--- C reproducer: // autogenerated by syzkaller (https://github.com/google/syzkaller) #define _GNU_SOURCE #include <endian.h> #include <errno.h> #include <pthread.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/syscall.h> #include <sys/types.h> #include <time.h> #include <unistd.h> #include <linux/futex.h> #ifndef __NR_bpf #define __NR_bpf 321 #endif static void sleep_ms(uint64_t ms) { usleep(ms * 1000); } static uint64_t current_time_ms(void) { struct timespec ts; if (clock_gettime(CLOCK_MONOTONIC, &ts)) exit(1); return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000; } static void thread_start(void* (*fn)(void*), void* arg) { pthread_t th; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setstacksize(&attr, 128 << 10); int i = 0; for (; i < 100; i++) { if (pthread_create(&th, &attr, fn, arg) == 0) { pthread_attr_destroy(&attr); return; } if (errno == EAGAIN) { usleep(50); continue; } break; } exit(1); } #define BITMASK(bf_off,bf_len) (((1ull << (bf_len)) - 1) << (bf_off)) #define STORE_BY_BITMASK(type,htobe,addr,val,bf_off,bf_len) *(type*)(addr) = htobe((htobe(*(type*)(addr)) & ~BITMASK((bf_off), (bf_len))) | (((type)(val) << (bf_off)) & BITMASK((bf_off), (bf_len)))) typedef struct { int state; } event_t; static void event_init(event_t* ev) { ev->state = 0; } static void event_reset(event_t* ev) { ev->state = 0; } static void event_set(event_t* ev) { if (ev->state) exit(1); __atomic_store_n(&ev->state, 1, __ATOMIC_RELEASE); syscall(SYS_futex, &ev->state, FUTEX_WAKE | FUTEX_PRIVATE_FLAG, 1000000); } static void event_wait(event_t* ev) { while (!__atomic_load_n(&ev->state, __ATOMIC_ACQUIRE)) syscall(SYS_futex, &ev->state, FUTEX_WAIT | FUTEX_PRIVATE_FLAG, 0, 0); } static int event_isset(event_t* ev) { return __atomic_load_n(&ev->state, __ATOMIC_ACQUIRE); } static int event_timedwait(event_t* ev, uint64_t timeout) { uint64_t start = current_time_ms(); uint64_t now = start; for (;;) { uint64_t remain = timeout - (now - start); struct timespec ts; ts.tv_sec = remain / 1000; ts.tv_nsec = (remain % 1000) * 1000 * 1000; syscall(SYS_futex, &ev->state, FUTEX_WAIT | FUTEX_PRIVATE_FLAG, 0, &ts); if (__atomic_load_n(&ev->state, __ATOMIC_ACQUIRE)) return 1; now = current_time_ms(); if (now - start > timeout) return 0; } } struct thread_t { int created, call; event_t ready, done; }; static struct thread_t threads[16]; static void execute_call(int call); static int running; static void* thr(void* arg) { struct thread_t* th = (struct thread_t*)arg; for (;;) { event_wait(&th->ready); event_reset(&th->ready); execute_call(th->call); __atomic_fetch_sub(&running, 1, __ATOMIC_RELAXED); event_set(&th->done); } return 0; } static void loop(void) { int i, call, thread; for (call = 0; call < 3; call++) { for (thread = 0; thread < (int)(sizeof(threads) / sizeof(threads[0])); thread++) { struct thread_t* th = &threads[thread]; if (!th->created) { th->created = 1; event_init(&th->ready); event_init(&th->done); event_set(&th->done); thread_start(thr, th); } if (!event_isset(&th->done)) continue; event_reset(&th->done); th->call = call; __atomic_fetch_add(&running, 1, __ATOMIC_RELAXED); event_set(&th->ready); event_timedwait(&th->done, 50 + (call == 0 ? 500 : 0)); break; } } for (i = 0; i < 100 && __atomic_load_n(&running, __ATOMIC_RELAXED); i++) sleep_ms(1); } uint64_t r[1] = {0xffffffffffffffff}; void execute_call(int call) { intptr_t res = 0; switch (call) { case 0: *(uint32_t*)0x20000000 = 6; *(uint32_t*)0x20000004 = 3; *(uint64_t*)0x20000008 = 0x200000c0; *(uint8_t*)0x200000c0 = 0x18; STORE_BY_BITMASK(uint8_t, , 0x200000c1, 0, 0, 4); STORE_BY_BITMASK(uint8_t, , 0x200000c1, 0, 4, 4); *(uint16_t*)0x200000c2 = 0; *(uint32_t*)0x200000c4 = 0; *(uint8_t*)0x200000c8 = 0; *(uint8_t*)0x200000c9 = 0; *(uint16_t*)0x200000ca = 0; *(uint32_t*)0x200000cc = 0; *(uint8_t*)0x200000d0 = 0x95; *(uint8_t*)0x200000d1 = 0; *(uint16_t*)0x200000d2 = 0; *(uint32_t*)0x200000d4 = 0; *(uint64_t*)0x20000010 = 0x20000100; memcpy((void*)0x20000100, "syzkaller\000", 10); *(uint32_t*)0x20000018 = 0; *(uint32_t*)0x2000001c = 0; *(uint64_t*)0x20000020 = 0; *(uint32_t*)0x20000028 = 0; *(uint32_t*)0x2000002c = 0; memset((void*)0x20000030, 0, 16); *(uint32_t*)0x20000040 = 0; *(uint32_t*)0x20000044 = 0x1b; *(uint32_t*)0x20000048 = -1; *(uint32_t*)0x2000004c = 8; *(uint64_t*)0x20000050 = 0; *(uint32_t*)0x20000058 = 0; *(uint32_t*)0x2000005c = 0x10; *(uint64_t*)0x20000060 = 0; *(uint32_t*)0x20000068 = 0; *(uint32_t*)0x2000006c = 0; *(uint32_t*)0x20000070 = 0; *(uint32_t*)0x20000074 = 0; *(uint64_t*)0x20000078 = 0; res = syscall(__NR_bpf, 5ul, 0x20000000ul, 0x80ul); if (res != -1) r[0] = res; break; case 1: *(uint32_t*)0x20000280 = r[0]; *(uint32_t*)0x20000284 = 0; *(uint32_t*)0x20000288 = 0; *(uint32_t*)0x2000028c = 0; *(uint64_t*)0x20000290 = 0; *(uint64_t*)0x20000298 = 0; *(uint32_t*)0x200002a0 = 0xffffff7f; *(uint32_t*)0x200002a4 = 0; *(uint32_t*)0x200002a8 = 0; *(uint32_t*)0x200002ac = 0; *(uint64_t*)0x200002b0 = 0; *(uint64_t*)0x200002b8 = 0; *(uint32_t*)0x200002c0 = 0; *(uint32_t*)0x200002c4 = 0; syscall(__NR_bpf, 0xaul, 0x20000280ul, 0x48ul); break; case 2: *(uint32_t*)0x200000c0 = 2; *(uint32_t*)0x200000c4 = 0x80; *(uint8_t*)0x200000c8 = 1; *(uint8_t*)0x200000c9 = 0; *(uint8_t*)0x200000ca = 0; *(uint8_t*)0x200000cb = 0; *(uint32_t*)0x200000cc = 0; *(uint64_t*)0x200000d0 = 0; *(uint64_t*)0x200000d8 = 0; *(uint64_t*)0x200000e0 = 0; STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 0, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 1, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 2, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 3, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 4, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 5, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 6, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 7, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 8, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 9, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 10, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 11, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 12, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 13, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 14, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 15, 2); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 17, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 18, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 19, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 20, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 21, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 22, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 23, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 24, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 25, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 26, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 27, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 28, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 29, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 30, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 31, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 32, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 33, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 34, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 35, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 36, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 37, 1); STORE_BY_BITMASK(uint64_t, , 0x200000e8, 0, 38, 26); *(uint32_t*)0x200000f0 = 0; *(uint32_t*)0x200000f4 = 2; *(uint64_t*)0x200000f8 = 0; *(uint64_t*)0x20000100 = 0; *(uint64_t*)0x20000108 = 0; *(uint64_t*)0x20000110 = 4; *(uint32_t*)0x20000118 = 0; *(uint32_t*)0x2000011c = 0; *(uint64_t*)0x20000120 = 0; *(uint32_t*)0x20000128 = 0; *(uint16_t*)0x2000012c = 0; *(uint16_t*)0x2000012e = 0; *(uint32_t*)0x20000130 = 0; *(uint32_t*)0x20000134 = 0; *(uint64_t*)0x20000138 = 0; syscall(__NR_perf_event_open, 0x200000c0ul, 0, 0ul, -1, 0ul); break; } } int main(void) { syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul); syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); loop(); return 0; } The following adapted patch is proposed to fix the bug on the 5.10.y kernel: [PATCH 5.10.y 1/1] bpf: Convert BPF_DISPATCHER to use static_call() (not ftrace)

11 months

2
3
0 0

[PATCH v5 RESEND 0/5] Regather scattered PCI-Code

by Philipp Stanner

Second Resend. Would be cool if someone could tell me what I'll have to do so we can get this merged. This is blocking the followup work I've got in the pipe -- @Stable-Kernel: You receive this patch series because its first patch fixes leaks in PCI. Changes in v5: - Add forgotten update to MAINTAINERS file. Changes in v4: - Apply Arnd's Reviewed-by's - Add ifdef CONFIG_HAS_IOPORT_MAP guard in drivers/pci/iomap.c (build error on openrisc) - Fix typo in patch no.5 Changes in v3: - Create a separate patch for the leaks in lib/iomap.c. Make it the series' first patch. (Arnd) - Turns out the aforementioned bug wasn't just accidentally removing iounmap() with the ifdef, it was also missing ioport_unmap() to begin with. Add it. - Move the ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT-mechanism from asm-generic/io.h to asm-generic/ioport.h. (Arnd) - Adjust the implementation of iomem_is_ioport() in asm-generic/io.h so that it matches exactly what pci_iounmap() previously did in lib/pci_iomap.c. (Arnd) - Move the CONFIG_HAS_IOPORT guard in asm-generic/io.h so that iomem_is_ioport() will always be compiled and just returns false if there are no ports. - Add TODOs to several places informing about the generic iomem_is_ioport() in lib/iomap.c not being generic. - Add TODO about the followup work to make drivers/pci/iomap.c's pci_iounmap() actually generic. Changes in v2: - Replace patch 4, previously extending the comment about pci_iounmap() in lib/iomap.c, with a patch that moves pci_iounmap() from that file to drivers/pci/iomap.c, creating a unified version there. (Arnd) - Implement iomem_is_ioport() as a new helper in asm-generic/io.h and lib/iomap.c. (Arnd) - Move the build rule in drivers/pci/Makefile for iomap.o under the guard of #if PCI. This had to be done because when just checking for GENERIC_PCI_IOMAP being defined, the functions don't disappear, which was the case previously in lib/pci_iomap.c, where the entire file was made empty if PCI was not set by the guard #ifdef PCI. (Intel's Bots) - Rephares all patches' commit messages a little bit. Sooooooooo. I reworked v1. Please review this carefully, the IO-Ranges are obviously a bit tricky, as is the build-system / ifdef-ery. Arnd has suggested that architectures defining a custom inb() need their own iomem_is_ioport(), as well. I've grepped for inb() and found the following list of archs that define their own: - alpha - arm - m68k <-- - parisc - powerpc - sh - sparc - x86 <-- All of those have their own definitons of pci_iounmap(). Therefore, they don't need our generic version in the first place and, thus, also need no iomem_is_ioport(). The two exceptions are x86 and m68k. The former uses lib/iomap.c through CONFIG_GENERIC_IOMAP, as Arnd pointed out in the previous discussion (thus, CONFIG_GENERIC_IOMAP is not really generic in this regard). So as I see it, only m68k WOULD need its own custom definition of iomem_is_ioport(). But as I understand it it doesn't because it uses the one from asm-generic/pci_iomap.h ?? I wasn't entirely sure how to deal with the address ranges for the generic implementation in asm-generic/io.h. It's marked with a TODO. Input appreciated. I removed the guard around define pci_iounmap in asm-generic/io.h. An alternative would be to have it be guarded by CONFIG_GENERIC_IOMAP and CONFIG_GENERIC_PCI_IOMAP, both. Without such a guard, there is no collision however, because generic pci_iounmap() from drivers/pci/iomap.c will only get pulled in when CONFIG_GENERIC_PCI_IOMAP is actually set. I cross-built this for a variety of architectures, including the usual suspects (s390, m68k). So far successfully. But let's see what Intel's robots say :O P. Original cover letter: Hi! So it seems that since ca. 2007 the PCI code has been scattered a bit. PCI's devres code, which is only ever used by users of the entire PCI-subsystem anyways, resides in lib/devres.c and is guarded by an ifdef PCI, just as the content of lib/pci_iomap.c is. It, thus, seems reasonable to move all of that. As I were at it, I moved as much of the devres-specific code from pci.c to devres.c, too. The only exceptions are four functions that are currently difficult to move. More information about that can be read here [1]. I noticed these scattered files while working on (new) PCI-specific devres functions. If we can get this here merged, I'll soon send another patch series that addresses some API-inconsistencies and could move the devres-part of the four remaining functions. I don't want to do that in this series as this here is only about moving code, whereas the next series would have to actually change API behavior. I successfully (cross-)built this for x86, x86_64, AARCH64 and ARM (allyesconfig). I booted a kernel with it on x86_64, with a Fedora desktop environment as payload. The OS came up fine I hope this is OK. If we can get it in, we'd soon have a very consistent PCI API again. Regards, P. Philipp Stanner (5): lib/pci_iomap.c: fix cleanup bugs in pci_iounmap() lib: move pci_iomap.c to drivers/pci/ lib: move pci-specific devres code to drivers/pci/ pci: move devres code from pci.c to devres.c lib, pci: unify generic pci_iounmap() MAINTAINERS | 1 - drivers/pci/Kconfig | 5 + drivers/pci/Makefile | 3 +- drivers/pci/devres.c | 450 +++++++++++++++++++++++++ lib/pci_iomap.c => drivers/pci/iomap.c | 49 +-- drivers/pci/pci.c | 249 -------------- drivers/pci/pci.h | 24 ++ include/asm-generic/io.h | 27 +- include/asm-generic/iomap.h | 21 ++ lib/Kconfig | 3 - lib/Makefile | 1 - lib/devres.c | 208 +----------- lib/iomap.c | 28 +- 13 files changed, 566 insertions(+), 503 deletions(-) create mode 100644 drivers/pci/devres.c rename lib/pci_iomap.c => drivers/pci/iomap.c (75%) -- 2.43.0

11 months

5
22
0 0

[PATCH] ASoC: amd: yc: Add DMI quirk for MSI Bravo 15 C7VF

by Bagas Sanjaya

From: Techno Mooney <techno.mooney(a)gmail.com> The laptop requires a quirk ID to enable its internal microphone. Add it to the DMI quirk table. Reported-by: Techno Mooney <techno.mooney(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218402 Cc: stable(a)vger.kernel.org Signed-off-by: Techno Mooney <techno.mooney(a)gmail.com> Signed-off-by: Bagas Sanjaya <bagasdotme(a)gmail.com> --- I'm not sure about reporter's identity (which also authored the quirk patch), hence I derived his name instead. Techno Mooney: is it OK to use above Reported-by: identity as-is? Developers: In this case, is it better to just use `Reported-by: <reporter's email>`? sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index d83cb6e4c62aec..23d44a50d81572 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -297,6 +297,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 B7ED"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."), + DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 C7VF"), + } + }, { .driver_data = &acp6x_card, .matches = { base-commit: aa8e3ef4fe5332c2ce33507e874b20d9c0077c21 -- An old man doll... just what I always wanted! - Clara

11 months

2
1
0 0

Re: [PATCH 6.7 000/346] 6.7.3-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (Intel Rocket Lake: i5-11400) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

11 months

1
0
0 0

FAILED: patch "[PATCH] LoongArch/smp: Call rcutree_report_cpu_starting() at" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 5056c596c3d1848021a4eaa76ee42f4c05c50346 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024012912-yahoo-patchwork-d338@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 5056c596c3d1 ("LoongArch/smp: Call rcutree_report_cpu_starting() at tlb_init()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5056c596c3d1848021a4eaa76ee42f4c05c50346 Mon Sep 17 00:00:00 2001 From: Huacai Chen <chenhuacai(a)kernel.org> Date: Fri, 26 Jan 2024 16:22:07 +0800 Subject: [PATCH] LoongArch/smp: Call rcutree_report_cpu_starting() at tlb_init() Machines which have more than 8 nodes fail to boot SMP after commit a2ccf46333d7b2cf96 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier"). Because such machines use tlb-based per-cpu base address rather than dmw-based per-cpu base address, resulting per-cpu variables can only be accessed after tlb_init(). But rcutree_report_cpu_starting() is now called before tlb_init() and accesses per-cpu variables indeed. Since the original patch want to avoid the lockdep warning caused by page allocation in tlb_init(), we can move rcutree_report_cpu_starting() to tlb_init() where after tlb exception configuration but before page allocation. Fixes: a2ccf46333d7b2cf96 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier") Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> diff --git a/arch/loongarch/kernel/smp.c b/arch/loongarch/kernel/smp.c index a16e3dbe9f09..2b49d30eb7c0 100644 --- a/arch/loongarch/kernel/smp.c +++ b/arch/loongarch/kernel/smp.c @@ -509,7 +509,6 @@ asmlinkage void start_secondary(void) sync_counter(); cpu = raw_smp_processor_id(); set_my_cpu_offset(per_cpu_offset(cpu)); - rcutree_report_cpu_starting(cpu); cpu_probe(); constant_clockevent_init(); diff --git a/arch/loongarch/mm/tlb.c b/arch/loongarch/mm/tlb.c index 2c0a411f23aa..0b95d32b30c9 100644 --- a/arch/loongarch/mm/tlb.c +++ b/arch/loongarch/mm/tlb.c @@ -284,12 +284,16 @@ static void setup_tlb_handler(int cpu) set_handler(EXCCODE_TLBNR * VECSIZE, handle_tlb_protect, VECSIZE); set_handler(EXCCODE_TLBNX * VECSIZE, handle_tlb_protect, VECSIZE); set_handler(EXCCODE_TLBPE * VECSIZE, handle_tlb_protect, VECSIZE); - } + } else { + int vec_sz __maybe_unused; + void *addr __maybe_unused; + struct page *page __maybe_unused; + + /* Avoid lockdep warning */ + rcutree_report_cpu_starting(cpu); + #ifdef CONFIG_NUMA - else { - void *addr; - struct page *page; - const int vec_sz = sizeof(exception_handlers); + vec_sz = sizeof(exception_handlers); if (pcpu_handlers[cpu]) return; @@ -305,8 +309,8 @@ static void setup_tlb_handler(int cpu) csr_write64(pcpu_handlers[cpu], LOONGARCH_CSR_EENTRY); csr_write64(pcpu_handlers[cpu], LOONGARCH_CSR_MERRENTRY); csr_write64(pcpu_handlers[cpu] + 80*VECSIZE, LOONGARCH_CSR_TLBRENTRY); - } #endif + } } void tlb_init(int cpu)

11 months

1
0
0 0

[PATCH 5.10.y] cifs: fix off-by-one in SMB2_query_info_init()

by Harshit Mogalapalli

Bug: After mounting the cifs fs, it complains with Resource temporarily unavailable messages. [root@vm1 xfstests-dev]# ./check -g quick -s smb3 TEST_DEV=//<SERVER_IP>/TEST is mounted but not a type cifs filesystem [root@vm1 xfstests-dev]# df df: /mnt/test: Resource temporarily unavailable Paul's analysis of the bug: Bug is related to an off-by-one in smb2_set_next_command() when the client attempts to pad SMB2_QUERY_INFO request -- since it isn't 8 byte aligned -- even though smb2_query_info_compound() doesn't provide an extra iov for such padding. v5.10.y doesn't have eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays") and the commit does if (unlikely(check_add_overflow(input_len, sizeof(*req), &len) || len > CIFSMaxBufSize)) return -EINVAL; so sizeof(*req) will wrongly include the extra byte from smb2_query_info_req::Buffer making @len unaligned and therefore causing OOB in smb2_set_next_command(). Fixes: 203a412e52b5 ("smb: client: fix OOB in SMB2_query_info_init()") Suggested-by: Paulo Alcantara <pc(a)manguebit.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- This patch is only for v5.10.y stable kernel. I have tested the patched kernel, after mounting it doesn't become unavailable. Context: [1] https://lore.kernel.org/all/CAH2r5mv2ipr4KJfMDXwHgq9L+kGdnRd1C2svcM=PCoDjA7… Note to Greg: This is alternative way to fix by not taking commit eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays"). before applying this patch a patch in the queue needs to be removed: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tre… As I have stated in [1] I am unsure the which is the best way, but this commit eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays") is not in 5.15.y so I think we shouldn't queue it in 5.10.y --- fs/cifs/smb2pdu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 76679dc4e6328..514e2cf44d951 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -3379,7 +3379,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server, iov[0].iov_base = (char *)req; /* 1 for Buffer */ - iov[0].iov_len = len; + iov[0].iov_len = len - 1; return 0; } -- 2.34.1

11 months

3
4
0 0

[PATCH 5.15.x] RDMA/irdma: Ensure iWarp QP queue memory is OS paged aligned

by Shiraz Saleem

From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> [ Upstream commit 0a5ec366de7e94192669ba08de6ed336607fd282 ] The SQ is shared for between kernel and used by storing the kernel page pointer and passing that to a kmap_atomic(). This then requires that the alignment is PAGE_SIZE aligned. Fix by adding an iWarp specific alignment check. The patch needed to be reworked because the separate routines present upstream are not there in older irdma drivers. Fixes: e965ef0e7b2c ("RDMA/irdma: Split QP handler into irdma_reg_user_mr_type_qp") Link: https://lore.kernel.org/r/20231129202143.1434-3-shiraz.saleem@intel.com Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/infiniband/hw/irdma/verbs.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/infiniband/hw/irdma/verbs.c b/drivers/infiniband/hw/irdma/verbs.c index 745712e1d7de..e02f541430ad 100644 --- a/drivers/infiniband/hw/irdma/verbs.c +++ b/drivers/infiniband/hw/irdma/verbs.c @@ -2783,6 +2783,11 @@ static struct ib_mr *irdma_reg_user_mr(struct ib_pd *pd, u64 start, u64 len, switch (req.reg_type) { case IRDMA_MEMREG_TYPE_QP: + /* iWarp: Catch page not starting on OS page boundary */ + if (!rdma_protocol_roce(&iwdev->ibdev, 1) && + ib_umem_offset(iwmr->region)) + return -EINVAL; + total = req.sq_pages + req.rq_pages + shadow_pgcnt; if (total > iwmr->page_cnt) { err = -EINVAL; -- 1.8.3.1

11 months

3
4
0 0

Re: Patch "driver core: Annotate dev_err_probe() with __must_check" has been added to the 4.19-stable tree

by Andy Shevchenko

On Fri, Jan 26, 2024 at 05:33:20PM -0800, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > driver core: Annotate dev_err_probe() with __must_check > > to the 4.19-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > driver-core-annotate-dev_err_probe-with-__must_check.patch > and it can be found in the queue-4.19 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. But it got reverted, no need to have it in any stable kernels. -- With Best Regards, Andy Shevchenko

11 months

2
1
0 0

FAILED: patch "[PATCH] clocksource: Skip watchdog check for large watchdog intervals" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 644649553508b9bacf0fc7a5bdc4f9e0165576a5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024012912-spoof-usual-3ce5@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 644649553508 ("clocksource: Skip watchdog check for large watchdog intervals") c37e85c135ce ("clocksource: Loosen clocksource watchdog constraints") fc153c1c58cb ("clocksource: Add a Kconfig option for WATCHDOG_MAX_SKEW") c86ff8c55b8a ("clocksource: Avoid accidental unstable marking of clocksources") 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold") db3a34e17433 ("clocksource: Retry clock read if long delays detected") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 644649553508b9bacf0fc7a5bdc4f9e0165576a5 Mon Sep 17 00:00:00 2001 From: Jiri Wiesner <jwiesner(a)suse.de> Date: Mon, 22 Jan 2024 18:23:50 +0100 Subject: [PATCH] clocksource: Skip watchdog check for large watchdog intervals There have been reports of the watchdog marking clocksources unstable on machines with 8 NUMA nodes: clocksource: timekeeping watchdog on CPU373: Marking clocksource 'tsc' as unstable because the skew is too large: clocksource: 'hpet' wd_nsec: 14523447520 clocksource: 'tsc' cs_nsec: 14524115132 The measured clocksource skew - the absolute difference between cs_nsec and wd_nsec - was 668 microseconds: cs_nsec - wd_nsec = 14524115132 - 14523447520 = 667612 The kernel used 200 microseconds for the uncertainty_margin of both the clocksource and watchdog, resulting in a threshold of 400 microseconds (the md variable). Both the cs_nsec and the wd_nsec value indicate that the readout interval was circa 14.5 seconds. The observed behaviour is that watchdog checks failed for large readout intervals on 8 NUMA node machines. This indicates that the size of the skew was directly proportinal to the length of the readout interval on those machines. The measured clocksource skew, 668 microseconds, was evaluated against a threshold (the md variable) that is suited for readout intervals of roughly WATCHDOG_INTERVAL, i.e. HZ >> 1, which is 0.5 second. The intention of 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold") was to tighten the threshold for evaluating skew and set the lower bound for the uncertainty_margin of clocksources to twice WATCHDOG_MAX_SKEW. Later in c37e85c135ce ("clocksource: Loosen clocksource watchdog constraints"), the WATCHDOG_MAX_SKEW constant was increased to 125 microseconds to fit the limit of NTP, which is able to use a clocksource that suffers from up to 500 microseconds of skew per second. Both the TSC and the HPET use default uncertainty_margin. When the readout interval gets stretched the default uncertainty_margin is no longer a suitable lower bound for evaluating skew - it imposes a limit that is far stricter than the skew with which NTP can deal. The root causes of the skew being directly proportinal to the length of the readout interval are: * the inaccuracy of the shift/mult pairs of clocksources and the watchdog * the conversion to nanoseconds is imprecise for large readout intervals Prevent this by skipping the current watchdog check if the readout interval exceeds 2 * WATCHDOG_INTERVAL. Considering the maximum readout interval of 2 * WATCHDOG_INTERVAL, the current default uncertainty margin (of the TSC and HPET) corresponds to a limit on clocksource skew of 250 ppm (microseconds of skew per second). To keep the limit imposed by NTP (500 microseconds of skew per second) for all possible readout intervals, the margins would have to be scaled so that the threshold value is proportional to the length of the actual readout interval. As for why the readout interval may get stretched: Since the watchdog is executed in softirq context the expiration of the watchdog timer can get severely delayed on account of a ksoftirqd thread not getting to run in a timely manner. Surely, a system with such belated softirq execution is not working well and the scheduling issue should be looked into but the clocksource watchdog should be able to deal with it accordingly. Fixes: 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold") Suggested-by: Feng Tang <feng.tang(a)intel.com> Signed-off-by: Jiri Wiesner <jwiesner(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Paul E. McKenney <paulmck(a)kernel.org> Reviewed-by: Feng Tang <feng.tang(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240122172350.GA740@incl diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index c108ed8a9804..3052b1f1168e 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -99,6 +99,7 @@ static u64 suspend_start; * Interval: 0.5sec. */ #define WATCHDOG_INTERVAL (HZ >> 1) +#define WATCHDOG_INTERVAL_MAX_NS ((2 * WATCHDOG_INTERVAL) * (NSEC_PER_SEC / HZ)) /* * Threshold: 0.0312s, when doubled: 0.0625s. @@ -134,6 +135,7 @@ static DECLARE_WORK(watchdog_work, clocksource_watchdog_work); static DEFINE_SPINLOCK(watchdog_lock); static int watchdog_running; static atomic_t watchdog_reset_pending; +static int64_t watchdog_max_interval; static inline void clocksource_watchdog_lock(unsigned long *flags) { @@ -399,8 +401,8 @@ static inline void clocksource_reset_watchdog(void) static void clocksource_watchdog(struct timer_list *unused) { u64 csnow, wdnow, cslast, wdlast, delta; + int64_t wd_nsec, cs_nsec, interval; int next_cpu, reset_pending; - int64_t wd_nsec, cs_nsec; struct clocksource *cs; enum wd_read_status read_ret; unsigned long extra_wait = 0; @@ -470,6 +472,27 @@ static void clocksource_watchdog(struct timer_list *unused) if (atomic_read(&watchdog_reset_pending)) continue; + /* + * The processing of timer softirqs can get delayed (usually + * on account of ksoftirqd not getting to run in a timely + * manner), which causes the watchdog interval to stretch. + * Skew detection may fail for longer watchdog intervals + * on account of fixed margins being used. + * Some clocksources, e.g. acpi_pm, cannot tolerate + * watchdog intervals longer than a few seconds. + */ + interval = max(cs_nsec, wd_nsec); + if (unlikely(interval > WATCHDOG_INTERVAL_MAX_NS)) { + if (system_state > SYSTEM_SCHEDULING && + interval > 2 * watchdog_max_interval) { + watchdog_max_interval = interval; + pr_warn("Long readout interval, skipping watchdog check: cs_nsec: %lld wd_nsec: %lld\n", + cs_nsec, wd_nsec); + } + watchdog_timer.expires = jiffies; + continue; + } + /* Check the deviation from the watchdog clocksource. */ md = cs->uncertainty_margin + watchdog->uncertainty_margin; if (abs(cs_nsec - wd_nsec) > md) {

11 months

1
0
0 0

FAILED: patch "[PATCH] clocksource: Skip watchdog check for large watchdog intervals" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 644649553508b9bacf0fc7a5bdc4f9e0165576a5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024012908-footing-happily-57fa@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 644649553508 ("clocksource: Skip watchdog check for large watchdog intervals") c37e85c135ce ("clocksource: Loosen clocksource watchdog constraints") fc153c1c58cb ("clocksource: Add a Kconfig option for WATCHDOG_MAX_SKEW") c86ff8c55b8a ("clocksource: Avoid accidental unstable marking of clocksources") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 644649553508b9bacf0fc7a5bdc4f9e0165576a5 Mon Sep 17 00:00:00 2001 From: Jiri Wiesner <jwiesner(a)suse.de> Date: Mon, 22 Jan 2024 18:23:50 +0100 Subject: [PATCH] clocksource: Skip watchdog check for large watchdog intervals There have been reports of the watchdog marking clocksources unstable on machines with 8 NUMA nodes: clocksource: timekeeping watchdog on CPU373: Marking clocksource 'tsc' as unstable because the skew is too large: clocksource: 'hpet' wd_nsec: 14523447520 clocksource: 'tsc' cs_nsec: 14524115132 The measured clocksource skew - the absolute difference between cs_nsec and wd_nsec - was 668 microseconds: cs_nsec - wd_nsec = 14524115132 - 14523447520 = 667612 The kernel used 200 microseconds for the uncertainty_margin of both the clocksource and watchdog, resulting in a threshold of 400 microseconds (the md variable). Both the cs_nsec and the wd_nsec value indicate that the readout interval was circa 14.5 seconds. The observed behaviour is that watchdog checks failed for large readout intervals on 8 NUMA node machines. This indicates that the size of the skew was directly proportinal to the length of the readout interval on those machines. The measured clocksource skew, 668 microseconds, was evaluated against a threshold (the md variable) that is suited for readout intervals of roughly WATCHDOG_INTERVAL, i.e. HZ >> 1, which is 0.5 second. The intention of 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold") was to tighten the threshold for evaluating skew and set the lower bound for the uncertainty_margin of clocksources to twice WATCHDOG_MAX_SKEW. Later in c37e85c135ce ("clocksource: Loosen clocksource watchdog constraints"), the WATCHDOG_MAX_SKEW constant was increased to 125 microseconds to fit the limit of NTP, which is able to use a clocksource that suffers from up to 500 microseconds of skew per second. Both the TSC and the HPET use default uncertainty_margin. When the readout interval gets stretched the default uncertainty_margin is no longer a suitable lower bound for evaluating skew - it imposes a limit that is far stricter than the skew with which NTP can deal. The root causes of the skew being directly proportinal to the length of the readout interval are: * the inaccuracy of the shift/mult pairs of clocksources and the watchdog * the conversion to nanoseconds is imprecise for large readout intervals Prevent this by skipping the current watchdog check if the readout interval exceeds 2 * WATCHDOG_INTERVAL. Considering the maximum readout interval of 2 * WATCHDOG_INTERVAL, the current default uncertainty margin (of the TSC and HPET) corresponds to a limit on clocksource skew of 250 ppm (microseconds of skew per second). To keep the limit imposed by NTP (500 microseconds of skew per second) for all possible readout intervals, the margins would have to be scaled so that the threshold value is proportional to the length of the actual readout interval. As for why the readout interval may get stretched: Since the watchdog is executed in softirq context the expiration of the watchdog timer can get severely delayed on account of a ksoftirqd thread not getting to run in a timely manner. Surely, a system with such belated softirq execution is not working well and the scheduling issue should be looked into but the clocksource watchdog should be able to deal with it accordingly. Fixes: 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold") Suggested-by: Feng Tang <feng.tang(a)intel.com> Signed-off-by: Jiri Wiesner <jwiesner(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Paul E. McKenney <paulmck(a)kernel.org> Reviewed-by: Feng Tang <feng.tang(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240122172350.GA740@incl diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index c108ed8a9804..3052b1f1168e 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -99,6 +99,7 @@ static u64 suspend_start; * Interval: 0.5sec. */ #define WATCHDOG_INTERVAL (HZ >> 1) +#define WATCHDOG_INTERVAL_MAX_NS ((2 * WATCHDOG_INTERVAL) * (NSEC_PER_SEC / HZ)) /* * Threshold: 0.0312s, when doubled: 0.0625s. @@ -134,6 +135,7 @@ static DECLARE_WORK(watchdog_work, clocksource_watchdog_work); static DEFINE_SPINLOCK(watchdog_lock); static int watchdog_running; static atomic_t watchdog_reset_pending; +static int64_t watchdog_max_interval; static inline void clocksource_watchdog_lock(unsigned long *flags) { @@ -399,8 +401,8 @@ static inline void clocksource_reset_watchdog(void) static void clocksource_watchdog(struct timer_list *unused) { u64 csnow, wdnow, cslast, wdlast, delta; + int64_t wd_nsec, cs_nsec, interval; int next_cpu, reset_pending; - int64_t wd_nsec, cs_nsec; struct clocksource *cs; enum wd_read_status read_ret; unsigned long extra_wait = 0; @@ -470,6 +472,27 @@ static void clocksource_watchdog(struct timer_list *unused) if (atomic_read(&watchdog_reset_pending)) continue; + /* + * The processing of timer softirqs can get delayed (usually + * on account of ksoftirqd not getting to run in a timely + * manner), which causes the watchdog interval to stretch. + * Skew detection may fail for longer watchdog intervals + * on account of fixed margins being used. + * Some clocksources, e.g. acpi_pm, cannot tolerate + * watchdog intervals longer than a few seconds. + */ + interval = max(cs_nsec, wd_nsec); + if (unlikely(interval > WATCHDOG_INTERVAL_MAX_NS)) { + if (system_state > SYSTEM_SCHEDULING && + interval > 2 * watchdog_max_interval) { + watchdog_max_interval = interval; + pr_warn("Long readout interval, skipping watchdog check: cs_nsec: %lld wd_nsec: %lld\n", + cs_nsec, wd_nsec); + } + watchdog_timer.expires = jiffies; + continue; + } + /* Check the deviation from the watchdog clocksource. */ md = cs->uncertainty_margin + watchdog->uncertainty_margin; if (abs(cs_nsec - wd_nsec) > md) {

11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024