May 2023 - Linux-stable-mirror

[PATCH v4 00/17] Venus QoL / maintainability fixes

by Konrad Dybcio

v3 -> v4: - Rebase on Stanimir's venus-for-next-v6.5 - Collapse 2 identical if-statements in "Sanitize venus_boot_core() per-VPU-version" - Reword "Assign registers based on VPU version" - Check for IS_IRIS2_1() instead of wrongly checking for core->use_tz, update commit msg in "media: venus: firmware: Correct IS_V6() checks" - Access correct struct fields in "Use newly-introduced hfi_buffer_requirements accessors", drop Bryan's r-b v3: https://lore.kernel.org/r/20230228-topic-venus-v3-0-6092ae43b58f@linaro.org v2 -> v3: - Rephrase "Write to VIDC_CTRL_INIT after unmasking interrupts" commit msg - Drop "Remap bufreq fields on HFI6XX" - Rephrase "Introduce VPU version distinction" commit msg - Better explain "Leave a clue for homegrown porters" - Drop incorrect fixes tags/rephrase version check alternations - Drop AR50L/IRIS1 from if-conditions, they'll be introduced separately - pick up tags - rebase on next-20230517 (no effective changes) v2: https://lore.kernel.org/r/20230228-topic-venus-v2-0-d95d14949c79@linaro.org v1 -> v2: - Move "Write to VIDC_CTRL_INIT after unmasking interrupts" up and add a Fixes tag & Cc stable - Reword the comment in "Correct IS_V6() checks" - Move up "media: venus: Remap bufreq fields on HFI6XX", add Fixes and Cc stable - Use better English in "Use newly-introduced hfi_buffer_requirements accessors" commit message - Mention "Restrict writing SCIACMDARG3 to Venus V1/V2" doesn't seem to regress SM8250 in the commit message - Pick up tags (note: I capitalized the R in Dikshita's 'reviewed-by' and removed one occurrence of random '**' to make sure review tools like b4 don't go crazy) - Handle AR50_LITE in "Assign registers based on VPU version" - Drop /* VPUn */ comments, they're invalid as explained by Vikash - Take a different approach to the sys_idle problem in patch 1 v1: https://lore.kernel.org/r/20230228-topic-venus-v1-0-58c2c88384e9@linaro.org Currently upstream assumes all (well, almost all - see 7280 or CrOS specific checks) Venus implementations using the same version of the Hardware Firmware Interface can be treated the same way. This is however not the case. This series tries to introduce the groundwork to start differentiating them based on the VPU (Video Processing Unit) hardware type, fixes a couple of issues that were an effect of that generalized assumption and lays the foundation for supporting 8150 (IRIS1) and SM6115/QCM2290 (AR50 Lite), which will hopefully come soon. Tested on 8250, but pretty please test it on your boards too! Signed-off-by: Konrad Dybcio <konrad.dybcio(a)linaro.org> --- Konrad Dybcio (17): media: venus: hfi_venus: Only consider sys_idle_indicator on V1 media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts media: venus: Introduce VPU version distinction media: venus: Add vpu_version to most SoCs media: venus: firmware: Leave a clue about obtaining CP VARs media: venus: hfi_venus: Sanitize venus_boot_core() per-VPU-version media: venus: core: Assign registers based on VPU version media: venus: hfi_venus: Sanitize venus_halt_axi() per-VPU-version media: venus: hfi_venus: Sanitize venus_isr() per-VPU-version media: venus: hfi_venus: Sanitize venus_cpu_and_video_core_idle() per-VPU-version media: venus: hfi_venus: Sanitize venus_cpu_idle_and_pc_ready() per-VPU-version media: venus: firmware: Sanitize per-VPU-version media: venus: hfi_platform: Check vpu_version instead of device compatible media: venus: vdec: Sanitize vdec_set_work_route() per-VPU-version media: venus: Introduce accessors for remapped hfi_buffer_reqs members media: venus: Use newly-introduced hfi_buffer_requirements accessors media: venus: hfi_venus: Restrict writing SCIACMDARG3 to Venus V1/V2 drivers/media/platform/qcom/venus/core.c | 7 ++- drivers/media/platform/qcom/venus/core.h | 15 ++++++ drivers/media/platform/qcom/venus/firmware.c | 18 +++++-- drivers/media/platform/qcom/venus/helpers.c | 7 +-- drivers/media/platform/qcom/venus/hfi_helper.h | 61 +++++++++++++++++++--- drivers/media/platform/qcom/venus/hfi_msgs.c | 2 +- .../media/platform/qcom/venus/hfi_plat_bufs_v6.c | 22 ++++---- drivers/media/platform/qcom/venus/hfi_platform.c | 2 +- drivers/media/platform/qcom/venus/hfi_venus.c | 42 +++++++-------- drivers/media/platform/qcom/venus/vdec.c | 10 ++-- drivers/media/platform/qcom/venus/vdec_ctrls.c | 2 +- drivers/media/platform/qcom/venus/venc.c | 4 +- drivers/media/platform/qcom/venus/venc_ctrls.c | 2 +- 13 files changed, 133 insertions(+), 61 deletions(-) --- base-commit: 9f9f8ca6f012d25428f8605cb36369a449db8508 change-id: 20230228-topic-venus-70ea3bc76688 Best regards, -- Konrad Dybcio <konrad.dybcio(a)linaro.org>

1 year, 9 months

2
3
0 0

[PATCH 2/2] drm/ofdrm: Update expected device name

by Cyril Brulebois

Since commit 241d2fb56a18 ("of: Make OF framebuffer device names unique"), as spotted by Frédéric Bonnard, the historical "of-display" device is gone: the updated logic creates "of-display.0" instead, then as many "of-display.N" as required. This means that offb no longer finds the expected device, which prevents the Debian Installer from setting up its interface, at least on ppc64el. Given the code similarity it is likely to affect ofdrm in the same way. It might be better to iterate on all possible nodes, but updating the hardcoded device from "of-display" to "of-display.0" is likely to help as a first step. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217328 Link: https://bugs.debian.org/1033058 Fixes: 241d2fb56a18 ("of: Make OF framebuffer device names unique") Cc: stable(a)vger.kernel.org # v6.2+ Signed-off-by: Cyril Brulebois <cyril(a)debamax.com> --- drivers/gpu/drm/tiny/ofdrm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c index 6e349ca42485..92df021d71df 100644 --- a/drivers/gpu/drm/tiny/ofdrm.c +++ b/drivers/gpu/drm/tiny/ofdrm.c @@ -1390,7 +1390,7 @@ MODULE_DEVICE_TABLE(of, ofdrm_of_match_display); static struct platform_driver ofdrm_platform_driver = { .driver = { - .name = "of-display", + .name = "of-display.0", .of_match_table = ofdrm_of_match_display, }, .probe = ofdrm_probe, -- 2.30.2

1 year, 9 months

6
6
0 0

[PATCH 1/2] fbdev/offb: Update expected device name

by Cyril Brulebois

Since commit 241d2fb56a18 ("of: Make OF framebuffer device names unique"), as spotted by Frédéric Bonnard, the historical "of-display" device is gone: the updated logic creates "of-display.0" instead, then as many "of-display.N" as required. This means that offb no longer finds the expected device, which prevents the Debian Installer from setting up its interface, at least on ppc64el. It might be better to iterate on all possible nodes, but updating the hardcoded device from "of-display" to "of-display.0" is confirmed to fix the Debian Installer at the very least. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217328 Link: https://bugs.debian.org/1033058 Fixes: 241d2fb56a18 ("of: Make OF framebuffer device names unique") Cc: stable(a)vger.kernel.org Signed-off-by: Cyril Brulebois <cyril(a)debamax.com> --- drivers/video/fbdev/offb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c index b97d251d894b..6264c7184457 100644 --- a/drivers/video/fbdev/offb.c +++ b/drivers/video/fbdev/offb.c @@ -698,7 +698,7 @@ MODULE_DEVICE_TABLE(of, offb_of_match_display); static struct platform_driver offb_driver_display = { .driver = { - .name = "of-display", + .name = "of-display.0", .of_match_table = offb_of_match_display, }, .probe = offb_probe_display, -- 2.30.2

1 year, 9 months

8
12
0 0

amd_sfh driver causes kernel oops during boot

by Haochen Tong

Hi, Since kernel 6.3.0 (and also 6.4rc3), on a ThinkPad Z13 system with Arch Linux, I've noticed that the amd_sfh driver spews a lot of stack traces during boot. Sometimes it is an oops: BUG: unable to handle page fault for address: 000000000001000f #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 457 Comm: (udev-worker) Not tainted 6.3.3-arch1-1 #1 fa7b7e0107004b3021a57a74b951e0a25e7e8584 Hardware name: LENOVO 21D2CTO1WW/21D2CTO1WW, BIOS N3GET47W (1.27 ) 12/08/2022 RIP: 0010:amd_sfh_get_report+0x1e/0x110 [amd_sfh] Code: 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 8b 87 60 1d 00 00 48 8b 68 08 <8b> 45 10 85 c0 0f 84 a9 00 00 00 49 89 fc 41 89 f7 41 89 d6 31 db RSP: 0018:ffffb164426f3a20 EFLAGS: 00010246 RAX: ffff9b0ae6b7bd00 RBX: ffff9b0ac0f46000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: ffff9b0ac0f46000 RBP: 000000000000ffff R08: ffffb164426f3ab8 R09: ffffb164426f3ab8 R10: 000000000020031b R11: ffff9b0ace40ac00 R12: ffff9b0ace40ac00 R13: 0000000000000002 R14: 0000000000000002 R15: ffff9b0acd213010 FS: 00007fe9ceb82200(0000) GS:ffff9b1122000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000001000f CR3: 000000010940c000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> amdtp_hid_request+0x36/0x50 [amd_sfh 2e3095779aada9fdb1764f08ca578ccb14e41fe4] sensor_hub_get_feature+0xad/0x170 [hid_sensor_hub d6157999c9d260a1bfa6f27d4a0dc2c3e2c5654e] hid_sensor_parse_common_attributes+0x217/0x310 [hid_sensor_iio_common 07a7935272aa9c7a28193b574580b3e953a64ec4] hid_gyro_3d_probe+0x7f/0x2e0 [hid_sensor_gyro_3d 9f2eb51294a1f0c0315b365f335617cbaef01eab] platform_probe+0x44/0xa0 really_probe+0x19e/0x3e0 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x160 driver_probe_device+0x1f/0x90 __driver_attach+0xd2/0x1c0 bus_for_each_dev+0x88/0xd0 bus_add_driver+0x116/0x220 driver_register+0x59/0x100 ? __pfx_init_module+0x10/0x10 [hid_sensor_gyro_3d 9f2eb51294a1f0c0315b365f335617cbaef01eab] do_one_initcall+0x5d/0x240 do_init_module+0x4a/0x200 __do_sys_init_module+0x17f/0x1b0 do_syscall_64+0x60/0x90 ? ksys_read+0x6f/0xf0 ? syscall_exit_to_user_mode+0x1b/0x40 ? do_syscall_64+0x6c/0x90 ? exc_page_fault+0x7c/0x180 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fe9ce721f9e Code: 48 8b 0d bd ed 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8a ed 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd280dd828 EFLAGS: 00000246 ORIG_RAX: 00000000000000af RAX: ffffffffffffffda RBX: 000055b72a37f630 RCX: 00007fe9ce721f9e RDX: 00007fe9cec7a343 RSI: 00000000000077f8 RDI: 000055b72a56c7f0 RBP: 00007fe9cec7a343 R08: 00000000000077f8 R09: 0000000000000000 R10: 000000000001a0a1 R11: 0000000000000246 R12: 0000000000020000 R13: 000055b72a363b90 R14: 000055b72a37f630 R15: 000055b72a36a070 </TASK> Modules linked in: hid_sensor_accel_3d(+) hid_sensor_gyro_3d(+) qrtr hid_sensor_trigger snd_sof industrialio_triggered_buffer ath11k_pci(+) kfifo_buf snd_sof_utils hid_sensor_iio_common joydev ath11k industrialio snd_soc_core mousedev qmi_helpers snd_compress hid_sensor_hub snd_hda_scodec_cs35l41_spi ac97_bus snd_hda_codec_realtek(+) snd_pcm_dmaengine intel_rapl_msr snd_hda_codec_hdmi snd_hda_codec_generic intel_rapl_common mac80211 snd_pci_ps btusb snd_rpl_pci_acp6x btrtl snd_hda_intel edac_mce_amd uvcvideo btbcm snd_acp_pci snd_intel_dspcfg snd_pci_acp6x videobuf2_vmalloc snd_intel_sdw_acpi libarc4 uvc btintel snd_usb_audio(+) snd_pci_acp5x videobuf2_memops btmtk snd_hda_codec kvm_amd videobuf2_v4l2 snd_hda_scodec_cs35l41_i2c snd_usbmidi_lib snd_hda_scodec_cs35l41 snd_rn_pci_acp3x ucsi_acpi bluetooth videodev snd_hda_core typec_ucsi snd_acp_config snd_hda_cs_dsp_ctls wacom(+) hid_multitouch cfg80211 snd_rawmidi sp5100_tco kvm snd_seq_device cs_dsp videobuf2_common typec ecdh_generic snd_soc_acpi think_lmi snd_hwdep snd_pcm irqbypass crc16 snd_soc_cs35l41_lib mhi thunderbolt firmware_attributes_class snd_pci_acp3x amd_sfh(+) k10temp psmouse roles rapl i2c_piix4 mc snd_timer wmi_bmof serial_multi_instantiate i2c_hid_acpi acpi_tad i2c_hid amd_pmf amd_pmc mac_hid sch_fq tcp_bbr dm_multipath i2c_dev crypto_user fuse loop zram ip_tables x_tables xfs libcrc32c crc32c_generic dm_crypt cbc encrypted_keys trusted asn1_encoder tee usbhid dm_mod amdgpu i2c_algo_bit serio_raw thinkpad_acpi drm_ttm_helper atkbd libps2 crct10dif_pclmul vivaldi_fmap crc32_pclmul ledtrig_audio crc32c_intel polyval_clmulni ttm polyval_generic drm_buddy nvme gf128mul platform_profile gpu_sched ghash_clmulni_intel sha512_ssse3 snd aesni_intel soundcore drm_display_helper crypto_simd rfkill nvme_core xhci_pci cryptd cec ccp xhci_pci_renesas i8042 video nvme_common serio wmi CR2: 000000000001000f ---[ end trace 0000000000000000 ]--- RIP: 0010:amd_sfh_get_report+0x1e/0x110 [amd_sfh] Code: 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 8b 87 60 1d 00 00 48 8b 68 08 <8b> 45 10 85 c0 0f 84 a9 00 00 00 49 89 fc 41 89 f7 41 89 d6 31 db RSP: 0018:ffffb164426f3a20 EFLAGS: 00010246 RAX: ffff9b0ae6b7bd00 RBX: ffff9b0ac0f46000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: ffff9b0ac0f46000 RBP: 000000000000ffff R08: ffffb164426f3ab8 R09: ffffb164426f3ab8 R10: 000000000020031b R11: ffff9b0ace40ac00 R12: ffff9b0ace40ac00 R13: 0000000000000002 R14: 0000000000000002 R15: ffff9b0acd213010 FS: 00007fe9ceb82200(0000) GS:ffff9b1122000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000001000f CR3: 000000010940c000 CR4: 0000000000750ee0 PKRU: 55555554 Sometimes it is a list corruption in the same function with a similar stack: ------------[ cut here ]------------ list_add corruption. next is NULL. WARNING: CPU: 5 PID: 433 at lib/list_debug.c:25 __list_add_valid+0x57/0xa0 ... CPU: 5 PID: 433 Comm: (udev-worker) Not tainted 6.4.0-rc3-1-mainline #1 b60166e85cb97a6631db26f9dcda0196ed7a0c93 Hardware name: LENOVO 21D2CTO1WW/21D2CTO1WW, BIOS N3GET47W (1.27 ) 12/08/2022 RIP: 0010:__list_add_valid+0x57/0xa0 Code: 01 00 00 00 c3 cc cc cc cc 48 c7 c7 58 91 e6 9a e8 1e b9 a8 ff 0f 0b 31 c0 c3 cc cc cc cc 48 c7 c7 80 91 e6 9a e8 09 b9 a8 ff <0f> 0b eb e9 48 89 c1 48 c7 c7 a8 91 e6 9a e8 f6 b8 a8 ff 0f 0b eb RSP: 0018:ffffad9dc0c7bb10 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff92d5a8099448 RCX: 0000000000000027 RDX: ffff92dbe1f61688 RSI: 0000000000000001 RDI: ffff92dbe1f61680 RBP: ffff92d59ea93508 R08: 0000000000000000 R09: ffffad9dc0c7b9a0 R10: 0000000000000003 R11: ffffffff9b6ca808 R12: 0000000000000000 R13: ffff92d5a8099440 R14: ffff92d59ea93760 R15: 0000000000000002 FS: 00007fbaf0262200(0000) GS:ffff92dbe1f40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005651de666000 CR3: 000000011cfee000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> amd_sfh_get_report+0xba/0x110 [amd_sfh 78bf82e66cdb2ccf24cbe871a0835ef4eedddb17] amdtp_hid_request+0x36/0x50 [amd_sfh 78bf82e66cdb2ccf24cbe871a0835ef4eedddb17] sensor_hub_get_feature+0xad/0x170 [hid_sensor_hub 30e53e2c49ea1702e2482c0b3860e22265679e39] hid_sensor_parse_common_attributes+0x217/0x310 [hid_sensor_iio_common ed7fba7a4d4147d48156e6a4b2a034ad3fc94350] hid_gyro_3d_probe+0x7f/0x2e0 [hid_sensor_gyro_3d 10978a2cdfc8979f2a7366fcd005e0ea826088eb] platform_probe+0x44/0xa0 really_probe+0x19e/0x3e0 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x160 driver_probe_device+0x1f/0x90 __driver_attach+0xd2/0x1c0 bus_for_each_dev+0x88/0xd0 bus_add_driver+0x116/0x220 driver_register+0x59/0x100 ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 10978a2cdfc8979f2a7366fcd005e0ea826088eb] do_one_initcall+0x5d/0x240 do_init_module+0x60/0x240 __do_sys_init_module+0x17f/0x1b0 do_syscall_64+0x60/0x90 ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fbaf06c0f9e Code: 48 8b 0d bd ed 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8a ed 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc5ce88528 EFLAGS: 00000246 ORIG_RAX: 00000000000000af RAX: ffffffffffffffda RBX: 00005651de36dff0 RCX: 00007fbaf06c0f9e RDX: 00007fbaf0ba9343 RSI: 00000000000079f0 RDI: 00005651de646fe0 RBP: 00007fbaf0ba9343 R08: 00000000000079f0 R09: 0000000000000000 R10: 0000000000019fb1 R11: 0000000000000246 R12: 0000000000020000 R13: 00005651de45fb10 R14: 00005651de36dff0 R15: 00005651de44d5f0 </TASK> ---[ end trace 0000000000000000 ]--- This occurs during almost every boot. When it happens there is usually a (udev-worker) process lingering forever, which is unkillable and even prevents shutdown. Looking at past journals it never happened before 6.3 so I believe it is a regression. Relevant device: 63:00.7 Signal processing controller [1180]: Advanced Micro Devices, Inc. [AMD] Sensor Fusion Hub [1022:15e4] Subsystem: Lenovo Sensor Fusion Hub [17aa:22f1] Kernel driver in use: pcie_mp2_amd Kernel modules: amd_sfh I would appreciate it if someone could take a look at this. Best regards, Haochen Tong

1 year, 9 months

7
20
0 0

[PATCH v4 1/3] mm: Call arch_swap_restore() from do_swap_page()

by Peter Collingbourne

Commit c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") moved the call to swap_free() before the call to set_pte_at(), which meant that the MTE tags could end up being freed before set_pte_at() had a chance to restore them. Fix it by adding a call to the arch_swap_restore() hook before the call to swap_free(). Signed-off-by: Peter Collingbourne <pcc(a)google.com> Link: https://linux-review.googlesource.com/id/I6470efa669e8bd2f841049b8c61020c51… Cc: <stable(a)vger.kernel.org> # 6.1 Fixes: c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") Reported-by: Qun-wei Lin (林群崴) <Qun-wei.Lin(a)mediatek.com> Closes: https://lore.kernel.org/all/5050805753ac469e8d727c797c2218a9d780d434.camel@… Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: "Huang, Ying" <ying.huang(a)intel.com> Reviewed-by: Steven Price <steven.price(a)arm.com> Acked-by: Catalin Marinas <catalin.marinas(a)arm.com> --- v2: - Call arch_swap_restore() directly instead of via arch_do_swap_page() mm/memory.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index f69fbc251198..fc25764016b3 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3932,6 +3932,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) } } + /* + * Some architectures may have to restore extra metadata to the page + * when reading from swap. This metadata may be indexed by swap entry + * so this must be called before swap_free(). + */ + arch_swap_restore(entry, folio); + /* * Remove the swap entry and conditionally try to free up the swapcache. * We're already holding a reference on the page but haven't mapped it -- 2.40.1.698.g37aff9b760-goog

1 year, 9 months

4
5
0 0

[PATCH] powerpc/boot: Disable power10 features after BOOTAFLAGS assignment

by Nathan Chancellor

When building the boot wrapper assembly files with clang after commit 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU"), the following warnings appear for each file built: '-prefixed' is not a recognized feature for this target (ignoring feature) '-pcrel' is not a recognized feature for this target (ignoring feature) While it is questionable whether or not LLVM should be emitting a warning when passed negative versions of code generation flags when building assembly files (since it does not emit a warning for the altivec and vsx flags), it is easy enough to work around this by just moving the disabled flags to BOOTCFLAGS after the assignment of BOOTAFLAGS, so that they are not added when building assembly files. Do so to silence the warnings. Cc: stable(a)vger.kernel.org Fixes: 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU") Link: https://github.com/ClangBuiltLinux/linux/issues/1839 Reviewed-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- I do not think that 648a1783fe25 is truly to blame for this but the Fixes tag will help the stable team ensure that this change gets backported with 648a1783fe25. This is the minimal fix for the problem but the true fix is separating AFLAGS and CFLAGS, which should be done by this in-flight series by Nick: https://lore.kernel.org/20230426055848.402993-1-npiggin@gmail.com/ --- arch/powerpc/boot/Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 85cde5bf04b7..771b79423bbc 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -34,8 +34,6 @@ endif BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \ - $(call cc-option,-mno-prefixed) $(call cc-option,-mno-pcrel) \ - $(call cc-option,-mno-mma) \ $(call cc-option,-mno-spe) $(call cc-option,-mspe=no) \ -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \ $(LINUXINCLUDE) @@ -71,6 +69,10 @@ BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc BOOTARFLAGS := -crD +BOOTCFLAGS += $(call cc-option,-mno-prefixed) \ + $(call cc-option,-mno-pcrel) \ + $(call cc-option,-mno-mma) + ifdef CONFIG_CC_IS_CLANG BOOTCFLAGS += $(CLANG_FLAGS) BOOTAFLAGS += $(CLANG_FLAGS) --- base-commit: 169f8997968ab620d750d9a45e15c5288d498356 change-id: 20230427-remove-power10-args-from-boot-aflags-clang-268c43e8c1fc Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 year, 9 months

2
1
0 0

[PATCH v2] powerpc/bpf: populate extable entries only during the last pass

by Hari Bathini

Since commit 85e031154c7c ("powerpc/bpf: Perform complete extra passes to update addresses"), two additional passes are performed to avoid space and CPU time wastage on powerpc. But these extra passes led to WARN_ON_ONCE() hits in bpf_add_extable_entry() as extable entries are populated again, during the extra pass, without resetting the index. Fix it by resetting entry index before repopulating extable entries, if and when there is an additional pass. Fixes: 85e031154c7c ("powerpc/bpf: Perform complete extra passes to update addresses") Cc: stable(a)vger.kernel.org Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> --- arch/powerpc/net/bpf_jit_comp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c index e93aefcfb83f..37043dfc1add 100644 --- a/arch/powerpc/net/bpf_jit_comp.c +++ b/arch/powerpc/net/bpf_jit_comp.c @@ -101,6 +101,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp) bpf_hdr = jit_data->header; proglen = jit_data->proglen; extra_pass = true; + /* During extra pass, ensure index is reset before repopulating extable entries */ + cgctx.exentry_idx = 0; goto skip_init_ctx; } -- 2.40.0

1 year, 9 months

3
2
0 0

Re: issues with cdc ncm host class driver

by Oliver Neukum

On 03.04.23 08:14, Purohit, Kaushal wrote: > Hi, > Hi, > Referring to patch with commit ID (*e10dcb1b6ba714243ad5a35a11b91cc14103a9a9*). > > This is a spec violation for CDC NCM class driver. Driver clearly says the significance of network capabilities. (snapshot below) > > However, with the mentioned patch these values are disrespected and commands specific to these capabilities are sent from the host regardless of device' capabilities to handle them. Right. So for your device, the correct behavior would be to do nothing, wouldn't it? The packets would be delivered and the host needs to filter and discard unrequested packets. > Currently we are setting these bits to 0 indicating no capabilities on our device and still we observe that Host (Linux kernel host cdc driver) has been sending requests specific to these capabilities. > > Please let me know if there is a better way to indicate host that device does not have these capabilities. no you are doing things as they are supposed to be done and the host is at fault. This kernel bug needs to be fixed. Regards Oliver

1 year, 9 months

3
4
0 0

arm64: fp-stress: BUG: KFENCE: memory corruption in fpsimd_release_task

by Naresh Kamboju

Following kernel BUG noticed while running selftests arm64 fp-stress running stable rc kernel versions 6.1.29-rc1 and 6.3.3-rc1. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> # selftests: arm64: fp-stress # TAP version 13 # 1..80 # # 8 CPUs, 3 SVE VLs, 3 SME VLs, SME2 absent # # Will run for 10s ... # # ZA-VL-32-4: PID: 1091 # # [ 263.834190] ================================================================== [ 263.834270] BUG: KFENCE: memory corruption in fpsimd_release_task+0x28/0x50 [ 263.834270] ZA-V[ 263.834419] Corrupted memory at 0x00000000d9c0a375 [ ! ! ! ! ! ! . . . . . . . . . . ] (in kfence-#158): L-64-[ 263.834929] fpsimd_release_task+0x28/0x50 [ 263.835074] arch_release_task_struct+0x1c/0x30 [ 263.835221] __put_task_struct+0x164/0x220 [ 263.835336] delayed_put_task_struct+0x60/0x128 4: [ 263.835484] rcu_core+0x318/0x950 [ 263.835632] rcu_core_si+0x1c/0x30 [ 263.835770] __do_softirq+0x110/0x3d8 Stre[ 263.835874] run_ksoftirqd+0x40/0xe0 [ 263.835994] smpboot_thread_fn+0x1d0/0x260 [ 263.836105] kthread+0xec/0x190 [ 263.836221] ret_from_fork+0x10/0x20 [ 263.836342] ami[ 263.836393] kfence-#158: 0x00000000c8819329-0x000000009e00cc22, size=546, cache=kmalloc-1k [ 263.836393] [ 263.836527] allocated by task 1112 on cpu 5 at 252.422888s: [ 263.836697] do_sme_acc+0xa8/0x230 ng m[ 263.836821] el0_sme_acc+0x40/0xa0 [ 263.836966] el0t_64_sync_handler+0xa8/0xf0 [ 263.837114] el0t_64_sync+0x190/0x198 [ 263.837224] ode[ 263.837275] freed by task 15 on cpu 0 at 263.833793s: [ 263.837500] fpsimd_release_task+0x28/0x50 [ 263.837629] arch_release_task_struct+0x1c/0x30 ve[ 263.837773] __put_task_struct+0x164/0x220 [ 263.837886] delayed_put_task_struct+0x60/0x128 [ 263.838032] rcu_core+0x318/0x950 cto[ 263.838176] rcu_core_si+0x1c/0x30 [ 263.838310] __do_softirq+0x110/0x3d8 [ 263.838417] run_ksoftirqd+0x40/0xe0 [ 263.838521] smpboot_thread_fn+0x1d0/0x260 [ 263.838626] kthread+0xec/0x190 [ 263.838742] ret_from_fork+0x10/0x20 [ 263.838861] [ 263.838913] CPU: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 6.3.3-rc1 #1 [ 263.839037] Hardware name: FVP Base RevC (DT) [ 263.839111] ================================================================== r length: 512 bits # # ZA-VL-64-4: PID: 1089 # # SSVE-VL-64-4: Streaming mode Vector length: 512 bits # # SSVE-VL-64-4: PID: 1088 # # ZA-VL-16-4: Streaming mode vector length: 128 bits # # ZA-VL-16-4: PID: 1093 # # FPSIMD-5-0: Vector length: 128 bits # # FPSIMD-5-0: PID: 1094 # # SVE-VL-32-5: Vector length: 256 bits # # SVE-VL-32-5: PID: 1096 # # SSVE-VL-64-5: Streaming mode Vector length: 512 bits # # SVE-VL-64-5: Vector length: 512 bits # # SVE-VL-64-5: PID: 1095 # # SSVE-VL-64-5: PID: 1098 # # ZA-VL-64-5:[ 263.905145] ================================================================== [ 263.905299] BUG: KFENCE: memory corruption in fpsimd_release_task+0x28/0x50 [ 263.905299] Str[ 263.905444] Corrupted memory at 0x00000000e3d2342a [ ! ! ! ! ! ! . . . . . . . . . . ] (in kfence-#146): [ 263.905957] fpsimd_release_task+0x28/0x50 eam[ 263.906088] arch_release_task_struct+0x1c/0x30 [ 263.906236] __put_task_struct+0x164/0x220 [ 263.906348] delayed_put_task_struct+0x60/0x128 [ 263.906499] rcu_core+0x318/0x950 [ 263.906647] rcu_core_si+0x1c/0x30 in[ 263.906786] __do_softirq+0x110/0x3d8 [ 263.906892] ____do_softirq+0x1c/0x30 [ 263.907015] call_on_irq_stack+0x24/0x58 g mo[ 263.907139] do_softirq_own_stack+0x28/0x40 [ 263.907305] __irq_exit_rcu+0x94/0xf8 [ 263.907454] irq_exit_rcu+0x1c/0x40 de [ 263.907599] el0_interrupt+0x58/0x160 [ 263.907765] __el0_irq_handler_common+0x18/0x28 [ 263.907879] el0t_64_irq_handler+0x10/0x20 [ 263.907989] el0t_64_irq+0x190/0x198 [ 263.908098] vect[ 263.908149] kfence-#146: 0x000000005a8569e6-0x00000000c704c501, size=546, cache=kmalloc-1k [ 263.908149] [ 263.908282] allocated by task 1102 on cpu 0 at 251.030980s: [ 263.908452] do_sme_acc+0xa8/0x230 or l[ 263.908576] el0_sme_acc+0x40/0xa0 [ 263.908725] el0t_64_sync_handler+0xa8/0xf0 [ 263.908879] el0t_64_sync+0x190/0x198 [ 263.908986] eng[ 263.909036] freed by task 1 on cpu 3 at 263.904989s: [ 263.909311] fpsimd_release_task+0x28/0x50 [ 263.909439] arch_release_task_struct+0x1c/0x30 th:[ 263.909584] __put_task_struct+0x164/0x220 [ 263.909696] delayed_put_task_struct+0x60/0x128 [ 263.909842] rcu_core+0x318/0x950 512 [ 263.909986] rcu_core_si+0x1c/0x30 [ 263.910175] __do_softirq+0x110/0x3d8 [ 263.910279] ____do_softirq+0x1c/0x30 [ 263.910399] call_on_irq_stack+0x24/0x58 [ 263.910520] do_softirq_own_stack+0x28/0x40 [ 263.910645] __irq_exit_rcu+0x94/0xf8 bits[ 263.910792] irq_exit_rcu+0x1c/0x40 [ 263.910937] el0_interrupt+0x58/0x160 [ 263.911043] __el0_irq_handler_common+0x18/0x28 [ 263.911154] el0t_64_irq_handler+0x10/0x20 [ 263.911261] el0t_64_irq+0x190/0x198 # # [ 263.911387] [ 263.911448] CPU: 3 PID: 1 Comm: systemd Tainted: G B 6.3.3-rc1 #1 [ 263.911575] Hardware name: FVP Base RevC (DT) [ 263.911653] ================================================================== .. # ok 80 ZA-VL-16-7 # # Totals: pass:80 fail:0 xfail:0 xpass:0 skip:0 error:0 ok 32 selftests: arm64: fp-stress Steps to reproduce: ============ # To install tuxrun on your system globally: # sudo pip3 install -U tuxrun==0.42.0 # # See https://tuxrun.org/ for complete documentation. tuxrun \ --runtime podman \ --device fvp-aemva \ --boot-args rw \ --kernel https://storage.tuxsuite.com/public/linaro/lkft/builds/2Pq5NvLiBcWRMuy6lXft… \ --modules https://storage.tuxsuite.com/public/linaro/lkft/builds/2Pq5NvLiBcWRMuy6lXft… \ --rootfs https://storage.tuxboot.com/debian/bookworm/arm64/rootfs.ext4.xz \ --parameters SKIPFILE=skipfile-lkft.yaml \ --parameters KSELFTEST=https://storage.tuxsuite.com/public/linaro/lkft/builds/2Pq5NvLiBc… \ --image tuxrun:fvp \ --tests kselftest-arm64 \ --timeouts boot=60 kselftest-arm64=60 Test log links: ======== - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.2… -- Linaro LKFT https://lkft.linaro.org

1 year, 9 months

5
15
0 0

[REGRESSION][BISECTED] Boot stall from merge tag 'net-next-6.2'

by Sami Korkalainen

Linux 6.2 and newer are (mostly) unbootable on my old HP 6730b laptop, the 6.1.30 works still fine. The weirdest thing is that newer kernels (like 6.3.4 and 6.4-rc3) may boot ok on the first try, but when rebooting, the very same version doesn't boot. Some times, when trying to boot, I get this message repeated forever: ACPI Error: No handler or method for GPE [XX], disabling event (20221020/evgpe-839) On newer kernels, the date is 20230331 instead of 20221020. There is also some other error, but I can't read it as it gets overwritten by the other ACPI error, see image linked at the end. And some times, the screen will just stay completely blank. I tried booting with acpi=off, but it does not help. I bisected and this is the first bad commit 7e68dd7d07a2 "Merge tag 'net-next-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next" As the later kernels had the seemingly random booting behaviour (mentioned above), I retested the last good one 7c4a6309e27f by booting it several times and it boots every time. I tried getting some boot logs, but the boot process does not go far enough to make any logs. Kernel .config file: https://0x0.st/Hqt1.txt Environment (outputs of a working Linux 6.1 build): Software (output of the ver_linux script): https://0x0.st/Hqte.txt Processor information (from /proc/cpuinfo): https://0x0.st/Hqt2.txt Module information (from /proc/modules): https://0x0.st/HqtL.txt /proc/ioports: https://0x0.st/Hqt9.txt /proc/iomem: https://0x0.st/Hqtf.txt PCI information ('lspci -vvv' as root): https://0x0.st/HqtO.txt SCSI information (from /proc/scsi/scsi) Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: KINGSTON SVP200S Rev: C4 Type: Direct-Access ANSI SCSI revision: 05 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: hp Model: CDDVDW TS-L633M Rev: 0301 Type: CD-ROM ANSI SCSI revision: 05 Distribution: Arch Linux Boot manager: systemd-boot (UEFI) git bisect log: https://0x0.st/Hqgx.txt ACPI Error (sorry for the dusty screen): https://0x0.st/HqEk.jpeg #regzbot ^introduced 7e68dd7d07a2 Best regards Sami Korkalainen

1 year, 9 months

9
26
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2023