March 2024 - Linux-stable-mirror

[PATCH] iommu: Avoid races around default domain allocations

by Nikhil V

From: Charan Teja Kalla <quic_charante(a)quicinc.com> This fix is applicable for LTS kernel, 6.1.y. In latest kernels, this race issue is fixed by the patch series [1] and [2]. The right thing to do here would have been propagating these changes from latest kernel to the stable branch, 6.1.y. However, these changes seems too intrusive to be picked for stable branches. Hence, the fix proposed can be taken as an alternative instead of backporting the patch series. [1] https://lore.kernel.org/all/0-v8-81230027b2fa+9d-iommu_all_defdom_jgg@nvidi… [2] https://lore.kernel.org/all/0-v5-1b99ae392328+44574-iommu_err_unwind_jgg@nv… Issue: A race condition is observed when arm_smmu_device_probe and modprobe of client devices happens in parallel. This results in the allocation of a new default domain for the iommu group even though it was previously allocated and the respective iova domain(iovad) was initialized. However, for this newly allocated default domain, iovad will not be initialized. As a result, for devices requesting dma allocations, this uninitialized iovad will be used, thereby causing NULL pointer dereference issue. Flow: - During arm_smmu_device_probe, bus_iommu_probe() will be called as part of iommu_device_register(). This results in the device probe, __iommu_probe_device(). - When the modprobe of the client device happens in parallel, it sets up the DMA configuration for the device using of_dma_configure_id(), which inturn calls iommu_probe_device(). Later, default domain is allocated and attached using iommu_alloc_default_domain() and __iommu_attach_device() respectively. It then ends up initializing a mapping domain(IOVA domain) and rcaches for the device via arch_setup_dma_ops()->iommu_setup_dma_ops(). - Now, in the bus_iommu_probe() path, it again tries to allocate a default domain via probe_alloc_default_domain(). This results in allocating a new default domain(along with IOVA domain) via __iommu_domain_alloc(). However, this newly allocated IOVA domain will not be initialized. - Now, when the same client device tries dma allocations via iommu_dma_alloc(), it ends up accessing the rcaches of the newly allocated IOVA domain, which is not initialized. This results into NULL pointer dereferencing. Fix this issue by adding a check in probe_alloc_default_domain() to see if the iommu_group already has a default domain allocated and initialized. Signed-off-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Co-developed-by: Nikhil V <quic_nprakash(a)quicinc.com> Signed-off-by: Nikhil V <quic_nprakash(a)quicinc.com> --- drivers/iommu/iommu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 8b3897239477..83736824f17d 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -1741,6 +1741,9 @@ static void probe_alloc_default_domain(struct bus_type *bus, { struct __group_domain_type gtype; + if (group->default_domain) + return; + memset(&gtype, 0, sizeof(gtype)); /* Ask for default domain requirements of all devices in the group */ -- 2.17.1

1 year, 3 months

3
4
0 0

[PATCH 5.4] xen/events: close evtchn after mapping cleanup

by Andrew Paniakin

From: Andrew Panyakin <apanyaki(a)amazon.com> From: Maximilian Heyne <mheyne(a)amazon.de> Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0xf0 ? bind_evtchn_to_cpu+0xc5/0xf0 set_affinity_irq+0xdc/0x1c0 irq_do_set_affinity+0x1d7/0x1f0 irq_setup_affinity+0xd6/0x1a0 irq_startup+0x8a/0xf0 __setup_irq+0x639/0x6d0 ? nvme_suspend+0x150/0x150 request_threaded_irq+0x10c/0x180 ? nvme_suspend+0x150/0x150 pci_request_irq+0xa8/0xf0 ? __blk_mq_free_request+0x74/0xa0 queue_request_irq+0x6f/0x80 nvme_create_queue+0x1af/0x200 nvme_create_io_queues+0xbd/0xf0 nvme_setup_io_queues+0x246/0x320 ? nvme_irq_check+0x30/0x30 nvme_reset_work+0x1c8/0x400 process_one_work+0x1b0/0x350 worker_thread+0x49/0x310 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 Modules linked in: ---[ end trace a11715de1eee1873 ]--- Fixes: d46a78b05c0e ("xen: implement pirq type event channels") Co-debugged-by: Andrew Panyakin <apanyaki(a)amazon.com> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> [apanyaki: backport to v5.4-stable] Signed-off-by: Andrew Paniakin <apanyaki(a)amazon.com> --- Compare to upstream patch this one does not have close_evtchn flag because there is no need to handle static event channels. This feature was added only in 58f6259b7a08f ("xen/evtchn: Introduce new IOCTL to bind static evtchn") drivers/xen/events/events_base.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 91806dc1236d..f8554d9a9f28 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -825,8 +825,8 @@ static void shutdown_pirq(struct irq_data *data) return; do_mask(info, EVT_MASK_REASON_EXPLICIT); - xen_evtchn_close(evtchn); xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } static void enable_pirq(struct irq_data *data) @@ -869,8 +869,6 @@ static void __unbind_from_irq(unsigned int irq) if (VALID_EVTCHN(evtchn)) { unsigned int cpu = cpu_from_irq(irq); - xen_evtchn_close(evtchn); - switch (type_from_irq(irq)) { case IRQT_VIRQ: per_cpu(virq_to_irq, cpu)[virq_from_irq(irq)] = -1; @@ -883,6 +881,7 @@ static void __unbind_from_irq(unsigned int irq) } xen_irq_info_cleanup(info); + xen_evtchn_close(evtchn); } xen_free_irq(irq); -- 2.40.1

1 year, 3 months

2
1
0 0

[PATCH V3 RESEND 0/3] Support intra-function call validation

by Rui Qi

Since kernel version 5.4.217 LTS, there has been an issue with the kernel live patching feature becoming unavailable. When compiling the sample code for kernel live patching, the following message is displayed when enabled: livepatch: klp_check_stack: kworker/u256:6:23490 has an unreliable stack Reproduction steps: 1.git checkout v5.4.269 -b v5.4.269 2.make defconfig 3. Set CONFIG_LIVEPATCH=y、CONFIG_SAMPLE_LIVEPATCH=m 4. make -j bzImage 5. make samples/livepatch/livepatch-sample.ko 6. qemu-system-x86_64 -kernel arch/x86_64/boot/bzImage -nographic -append "console=ttyS0" -initrd initrd.img -m 1024M 7. insmod livepatch-sample.ko Kernel live patch cannot complete successfully. After some debugging, the immediate cause of the patch failure is an error in stack checking. The logs are as follows: [ 340.974853] livepatch: klp_check_stack: kworker/u256:0:23486 has an unreliable stack [ 340.974858] livepatch: klp_check_stack: kworker/u256:1:23487 has an unreliable stack [ 340.974863] livepatch: klp_check_stack: kworker/u256:2:23488 has an unreliable stack [ 340.974868] livepatch: klp_check_stack: kworker/u256:5:23489 has an unreliable stack [ 340.974872] livepatch: klp_check_stack: kworker/u256:6:23490 has an unreliable stack ...... BTW,if you use the v5.4.217 tag for testing, make sure to set CONFIG_RETPOLINE = y and CONFIG_LIVEPATCH = y, and other steps are consistent with v5.4.269 After investigation, The problem is strongly related to the commit 8afd1c7da2b0 ("x86/speculation: Change FILL_RETURN_BUFFER to work with objtool"), which would cause incorrect ORC entries to be generated, and the v5.4.217 version can undo this commit to make kernel livepatch work normally. It is a back-ported upstream patch with some code adjustments,from the git log, the author also mentioned no intra-function call validation support. Based on commit 24489321d0cd5339f9c2da01eb8bf2bccbac7956 (Linux 5.4.273), This patchset adds stack validation support for intra-function calls, allowing the kernel live patching feature to work correctly. v3 - v2 - fix the compile error in arch/x86/kvm/svm.c, the error message is../arch/x86/include/asm/nospec-branch.h: 313: Error: no such instruction: 'unwind_hint_empty' v2 - v1 - add the tag "Cc: stable(a)vger.kernel.org" in the sign-off area for patch x86/speculation: Support intra-function call - add my own Signed-off to all patches s Alexandre Chartre (2): objtool: is_fentry_call() crashes if call has no destination objtool: Add support for intra-function calls Rui Qi (1): x86/speculation: Support intra-function call validation arch/x86/include/asm/nospec-branch.h | 7 ++ arch/x86/include/asm/unwind_hints.h | 2 +- include/linux/frame.h | 11 ++++ .../Documentation/stack-validation.txt | 8 +++ tools/objtool/arch/x86/decode.c | 6 ++ tools/objtool/check.c | 64 +++++++++++++++++-- 6 files changed, 92 insertions(+), 6 deletions(-) -- 2.20.1

1 year, 3 months

2
4
0 0

[PATCH 6.6 00/24] xfs backports for 6.6.y (from 6.8)

by Catherine Hoang

Hello, This series contains backports for 6.6 from the 6.8 release. This patchset has gone through xfs testing and review. Andrey Albershteyn (1): xfs: reset XFS_ATTR_INCOMPLETE filter on node removal Christoph Hellwig (1): xfs: consider minlen sized extents in xfs_rtallocate_extent_block Darrick J. Wong (16): xfs: move the xfs_rtbitmap.c declarations to xfs_rtbitmap.h xfs: convert rt bitmap extent lengths to xfs_rtbxlen_t xfs: don't leak recovered attri intent items xfs: use xfs_defer_pending objects to recover intent items xfs: pass the xfs_defer_pending object to iop_recover xfs: transfer recovered intent item ownership in ->iop_recover xfs: make rextslog computation consistent with mkfs xfs: fix 32-bit truncation in xfs_compute_rextslog xfs: don't allow overly small or large realtime volumes xfs: make xchk_iget safer in the presence of corrupt inode btrees xfs: remove unused fields from struct xbtree_ifakeroot xfs: recompute growfsrtfree transaction reservation while growing rt volume xfs: fix an off-by-one error in xreap_agextent_binval xfs: force all buffers to be written during btree bulk load xfs: add missing nrext64 inode flag check to scrub xfs: remove conditional building of rt geometry validator functions Dave Chinner (1): xfs: initialise di_crc in xfs_log_dinode Eric Sandeen (1): xfs: short circuit xfs_growfs_data_private() if delta is zero Jiachen Zhang (1): xfs: ensure logflagsp is initialized in xfs_bmap_del_extent_real Long Li (2): xfs: add lock protection when remove perag from radix tree xfs: fix perag leak when growfs fails Zhang Tianci (1): xfs: update dir3 leaf block metadata after swap fs/xfs/libxfs/xfs_ag.c | 36 +++++++-- fs/xfs/libxfs/xfs_ag.h | 2 + fs/xfs/libxfs/xfs_attr.c | 6 +- fs/xfs/libxfs/xfs_bmap.c | 75 ++++++++----------- fs/xfs/libxfs/xfs_btree_staging.c | 4 +- fs/xfs/libxfs/xfs_btree_staging.h | 6 -- fs/xfs/libxfs/xfs_da_btree.c | 7 ++ fs/xfs/libxfs/xfs_defer.c | 105 +++++++++++++++++++------- fs/xfs/libxfs/xfs_defer.h | 5 ++ fs/xfs/libxfs/xfs_format.h | 2 +- fs/xfs/libxfs/xfs_log_recover.h | 5 ++ fs/xfs/libxfs/xfs_rtbitmap.c | 2 + fs/xfs/libxfs/xfs_rtbitmap.h | 83 +++++++++++++++++++++ fs/xfs/libxfs/xfs_sb.c | 20 ++++- fs/xfs/libxfs/xfs_sb.h | 2 + fs/xfs/libxfs/xfs_types.h | 13 ++++ fs/xfs/scrub/common.c | 6 +- fs/xfs/scrub/common.h | 25 +++++++ fs/xfs/scrub/fscounters.c | 2 +- fs/xfs/scrub/inode.c | 8 +- fs/xfs/scrub/reap.c | 2 +- fs/xfs/scrub/rtbitmap.c | 3 +- fs/xfs/scrub/rtsummary.c | 3 +- fs/xfs/scrub/trace.h | 3 +- fs/xfs/xfs_attr_item.c | 23 +++--- fs/xfs/xfs_bmap_item.c | 14 ++-- fs/xfs/xfs_buf.c | 44 ++++++++++- fs/xfs/xfs_buf.h | 1 + fs/xfs/xfs_extfree_item.c | 14 ++-- fs/xfs/xfs_fsmap.c | 2 +- fs/xfs/xfs_fsops.c | 9 ++- fs/xfs/xfs_inode_item.c | 3 + fs/xfs/xfs_log.c | 1 + fs/xfs/xfs_log_priv.h | 1 + fs/xfs/xfs_log_recover.c | 118 ++++++++++++++++-------------- fs/xfs/xfs_refcount_item.c | 13 ++-- fs/xfs/xfs_rmap_item.c | 14 ++-- fs/xfs/xfs_rtalloc.c | 14 +++- fs/xfs/xfs_rtalloc.h | 73 ------------------ fs/xfs/xfs_trans.h | 4 +- 40 files changed, 492 insertions(+), 281 deletions(-) create mode 100644 fs/xfs/libxfs/xfs_rtbitmap.h -- 2.39.3

1 year, 3 months

2
25
0 0

[PATCH 2/2] tracing: Remove unnecessary var destroy in onmax_destroy()

by George Guo

From: George Guo <guodongtai(a)kylinos.cn> The onmax_destroy() destroyed the onmax var, casusing a double-free error flagged by KASAN. This is tested via "./ftracetest test.d/trigger/inter-event/ trigger-onmatch-onmax-action-hist.tc". ================================================================== BUG: KASAN: use-after-free in destroy_hist_field+0x1c2/0x200 Read of size 8 at addr ffff88800a4ad100 by task ftracetest/4731 CPU: 0 PID: 4731 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #77 Source Version: Unknown Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0 Call Trace: dump_stack+0xcb/0x10b print_address_description.cold+0x54/0x249 kasan_report_error.cold+0x63/0xab ? destroy_hist_field+0x1c2/0x200 ? hist_trigger_elt_data_alloc+0x5a0/0x5a0 __asan_report_load8_noabort+0x8d/0xa0 ? destroy_hist_field+0x1c2/0x200 destroy_hist_field+0x1c2/0x200 onmax_destroy+0x72/0x1e0 ? hist_trigger_elt_data_alloc+0x5a0/0x5a0 destroy_hist_data+0x236/0xa40 event_hist_trigger_free+0x212/0x2f0 ? update_cond_flag+0x128/0x170 ? event_hist_trigger_func+0x2880/0x2880 hist_unregister_trigger+0x2f2/0x4f0 event_hist_trigger_func+0x168c/0x2880 ? tracing_map_cmp_u64+0xa0/0xa0 ? onmatch_create.constprop.0+0xf50/0xf50 ? __mutex_lock_slowpath+0x10/0x10 event_trigger_write+0x2f4/0x490 ? trigger_start+0x180/0x180 ? __fget_light+0x369/0x5d0 ? count_memcg_event_mm+0x104/0x2b0 ? trigger_start+0x180/0x180 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x540 ksys_write+0x12a/0x290 ? __ia32_sys_read+0xb0/0xb0 ? __close_fd+0x1d3/0x280 do_syscall_64+0xe3/0x2d0 entry_SYSCALL_64_after_hwframe+0x5c/0xc1 RIP: 0033:0x7fd7f4c44e04 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 RSP: 002b:00007fff10370df8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000010f RCX: 00007fd7f4c44e04 RDX: 000000000000010f RSI: 000055fa765df650 RDI: 0000000000000001 RBP: 000055fa765df650 R08: 000000000000000a R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000246 R12: 00007fd7f4d035c0 R13: 000000000000010f R14: 00007fd7f4d037c0 R15: 000000000000010f ================================================================== So remove the onmax_destroy() destroy_hist_field() call for that var. Fixes: 50450603ec9c("tracing: Add 'onmax' hist trigger action support") Cc: stable(a)vger.kernel.org Signed-off-by: George Guo <guodongtai(a)kylinos.cn> --- kernel/trace/trace_events_hist.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index 7dcb96305e56..58b8a2575b8c 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -337,7 +337,6 @@ struct action_data { char *fn_name; unsigned int max_var_ref_idx; struct hist_field *max_var; - struct hist_field *var; } onmax; }; }; @@ -3489,7 +3488,6 @@ static void onmax_destroy(struct action_data *data) unsigned int i; destroy_hist_field(data->onmax.max_var, 0); - destroy_hist_field(data->onmax.var, 0); kfree(data->onmax.var_str); kfree(data->onmax.fn_name); @@ -3528,8 +3526,6 @@ static int onmax_create(struct hist_trigger_data *hist_data, if (!ref_field) return -ENOMEM; - data->onmax.var = ref_field; - data->fn = onmax_save; data->onmax.max_var_ref_idx = var_ref_idx; max_var = create_var(hist_data, file, "max", sizeof(u64), "u64"); -- 2.34.1

1 year, 3 months

2
1
0 0

[PATCH 1/2] tracing: Remove unnecessary hist_data destroy in destroy_synth_var_refs()

by George Guo

From: George Guo <guodongtai(a)kylinos.cn> The destroy_synth_var_refs() destroyed hist_data, casusing a double-free error flagged by KASAN. This is tested via "./ftracetest test.d/trigger/inter-event/ trigger-field-variable-support.tc" ================================================================== BUG: KASAN: use-after-free in destroy_hist_field+0x115/0x140 Read of size 4 at addr ffff888012e95318 by task ftracetest/1858 CPU: 1 PID: 1858 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #24 Source Version: Unknown Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0 Call Trace: dump_stack+0xcb/0x10b print_address_description.cold+0x54/0x249 kasan_report_error.cold+0x63/0xab ? destroy_hist_field+0x115/0x140 __asan_report_load4_noabort+0x8d/0xa0 ? destroy_hist_field+0x115/0x140 destroy_hist_field+0x115/0x140 destroy_hist_data+0x4e4/0x9a0 event_hist_trigger_free+0x212/0x2f0 ? update_cond_flag+0x128/0x170 ? event_hist_trigger_func+0x2880/0x2880 hist_unregister_trigger+0x2f2/0x4f0 event_hist_trigger_func+0x168c/0x2880 ? tracing_map_read_var_once+0xd0/0xd0 ? create_key_field+0x520/0x520 ? __mutex_lock_slowpath+0x10/0x10 event_trigger_write+0x2f4/0x490 ? trigger_start+0x180/0x180 ? __fget_light+0x369/0x5d0 ? count_memcg_event_mm+0x104/0x2b0 ? trigger_start+0x180/0x180 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x540 ksys_write+0x12a/0x290 ? __ia32_sys_read+0xb0/0xb0 ? __close_fd+0x1d3/0x280 do_syscall_64+0xe3/0x2d0 entry_SYSCALL_64_after_hwframe+0x5c/0xc1 RIP: 0033:0x7efdd342ee04 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 RSP: 002b:00007ffda01f5e08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000000000b4 RCX: 00007efdd342ee04 RDX: 00000000000000b4 RSI: 000055c5b41b1e90 RDI: 0000000000000001 RBP: 000055c5b41b1e90 R08: 000000000000000a R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000246 R12: 00007efdd34ed5c0 R13: 00000000000000b4 R14: 00007efdd34ed7c0 R15: 00000000000000b4 ================================================================== So remove the destroy_synth_var_refs() call for that hist_data. Fixes: c282a386a397("tracing: Add 'onmatch' hist trigger action support") Cc: stable(a)vger.kernel.org Signed-off-by: George Guo <guodongtai(a)kylinos.cn> --- kernel/trace/trace_events_hist.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index e004daf8cad5..7dcb96305e56 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -280,8 +280,6 @@ struct hist_trigger_data { struct action_data *actions[HIST_ACTIONS_MAX]; unsigned int n_actions; - struct hist_field *synth_var_refs[SYNTH_FIELDS_MAX]; - unsigned int n_synth_var_refs; struct field_var *field_vars[SYNTH_FIELDS_MAX]; unsigned int n_field_vars; unsigned int n_field_var_str; @@ -1363,8 +1361,8 @@ static struct hist_field *find_var_ref(struct hist_trigger_data *hist_data, return found; } - for (i = 0; i < hist_data->n_synth_var_refs; i++) { - hist_field = hist_data->synth_var_refs[i]; + for (i = 0; i < hist_data->n_var_refs; i++) { + hist_field = hist_data->var_refs[i]; found = check_field_for_var_refs(hist_data, hist_field, var_data, var_idx, 0); if (found) @@ -3707,21 +3705,6 @@ static void save_field_var(struct hist_trigger_data *hist_data, hist_data->n_field_var_str++; } - -static void destroy_synth_var_refs(struct hist_trigger_data *hist_data) -{ - unsigned int i; - - for (i = 0; i < hist_data->n_synth_var_refs; i++) - destroy_hist_field(hist_data->synth_var_refs[i], 0); -} - -static void save_synth_var_ref(struct hist_trigger_data *hist_data, - struct hist_field *var_ref) -{ - hist_data->synth_var_refs[hist_data->n_synth_var_refs++] = var_ref; -} - static int check_synth_field(struct synth_event *event, struct hist_field *hist_field, unsigned int field_pos) @@ -3884,7 +3867,6 @@ static int onmatch_create(struct hist_trigger_data *hist_data, goto err; } - save_synth_var_ref(hist_data, var_ref); field_pos++; kfree(p); continue; @@ -4631,7 +4613,6 @@ static void destroy_hist_data(struct hist_trigger_data *hist_data) destroy_actions(hist_data); destroy_field_vars(hist_data); destroy_field_var_hists(hist_data); - destroy_synth_var_refs(hist_data); kfree(hist_data); } -- 2.34.1

1 year, 3 months

2
1
0 0

Re: [PATCH stable 5.10] serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO

by Gong Ruiqi

Oops. + Cc stable(a)vger.kernel.org On 2024/03/18 10:52, GONG, Ruiqi wrote: > From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> > > commit dbf4ab821804df071c8b566d9813083125e6d97b upstream. > > The SC16IS7XX IC supports a burst mode to access the FIFOs where the > initial register address is sent ($00), followed by all the FIFO data > without having to resend the register address each time. In this mode, the > IC doesn't increment the register address for each R/W byte. > > The regmap_raw_read() and regmap_raw_write() are functions which can > perform IO over multiple registers. They are currently used to read/write > from/to the FIFO, and although they operate correctly in this burst mode on > the SPI bus, they would corrupt the regmap cache if it was not disabled > manually. The reason is that when the R/W size is more than 1 byte, these > functions assume that the register address is incremented and handle the > cache accordingly. > > Convert FIFO R/W functions to use the regmap _noinc_ versions in order to > remove the manual cache control which was a workaround when using the > _raw_ versions. FIFO registers are properly declared as volatile so > cache will not be used/updated for FIFO accesses. > > Fixes: dfeae619d781 ("serial: sc16is7xx") > Cc: <stable(a)vger.kernel.org> > Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> > Link: https://lore.kernel.org/r/20231211171353.2901416-6-hugo@hugovil.com > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Cc: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> > Signed-off-by: GONG, Ruiqi <gongruiqi1(a)huawei.com> > --- > > The mainline commit dbf4ab821804 ("serial: sc16is7xx: convert from _raw_ > to _noinc_ regmap functions for FIFO") by Hugo has been assigned to be > CVE-2023-52488, but for stable branches lower than 6.1 there's no > official backport. > > I made up this backport patch for 5.10, and its correctness has been > confirmed in previous communication with Hugo. Let's publicize it and > merge it into upstream. > > drivers/tty/serial/sc16is7xx.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c > index 31e0c5c3ddea..29f05db0d49b 100644 > --- a/drivers/tty/serial/sc16is7xx.c > +++ b/drivers/tty/serial/sc16is7xx.c > @@ -376,9 +376,7 @@ static void sc16is7xx_fifo_read(struct uart_port *port, unsigned int rxlen) > const u8 line = sc16is7xx_line(port); > u8 addr = (SC16IS7XX_RHR_REG << SC16IS7XX_REG_SHIFT) | line; > > - regcache_cache_bypass(s->regmap, true); > - regmap_raw_read(s->regmap, addr, s->buf, rxlen); > - regcache_cache_bypass(s->regmap, false); > + regmap_noinc_read(s->regmap, addr, s->buf, rxlen); > } > > static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send) > @@ -394,9 +392,7 @@ static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send) > if (unlikely(!to_send)) > return; > > - regcache_cache_bypass(s->regmap, true); > - regmap_raw_write(s->regmap, addr, s->buf, to_send); > - regcache_cache_bypass(s->regmap, false); > + regmap_noinc_write(s->regmap, addr, s->buf, to_send); > } > > static void sc16is7xx_port_update(struct uart_port *port, u8 reg, > @@ -489,6 +485,11 @@ static bool sc16is7xx_regmap_precious(struct device *dev, unsigned int reg) > return false; > } > > +static bool sc16is7xx_regmap_noinc(struct device *dev, unsigned int reg) > +{ > + return reg == SC16IS7XX_RHR_REG; > +} > + > static int sc16is7xx_set_baud(struct uart_port *port, int baud) > { > struct sc16is7xx_port *s = dev_get_drvdata(port->dev); > @@ -1439,6 +1440,8 @@ static struct regmap_config regcfg = { > .cache_type = REGCACHE_RBTREE, > .volatile_reg = sc16is7xx_regmap_volatile, > .precious_reg = sc16is7xx_regmap_precious, > + .writeable_noinc_reg = sc16is7xx_regmap_noinc, > + .readable_noinc_reg = sc16is7xx_regmap_noinc, > }; > > #ifdef CONFIG_SERIAL_SC16IS7XX_SPI

1 year, 3 months

2
1
0 0

[PATCH] wifi: rtw88: 8821cu: Fix connection failure

by Bitterblue Smith

From: Bitterblue Smith <rtl8821cerfe2(a)gmail.com> [ Upstream commit 605d7c0b05eecb985273b1647070497142c470d3 ] Clear bit 8 of REG_SYS_STATUS1 after MAC power on. Without this, some RTL8821CU and RTL8811CU cannot connect to any network: Feb 19 13:33:11 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 1/3) Feb 19 13:33:13 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 2/3) Feb 19 13:33:14 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 3/3) Feb 19 13:33:15 ideapad2 kernel: wlp3s0f3u2: authentication with 90:55:de:__:__:__ timed out The RTL8822CU and RTL8822BU out-of-tree drivers do this as well, so do it for all three types of chips. Tested with RTL8811CU (Tenda U9 V2.0). Signed-off-by: Bitterblue Smith <rtl8821cerfe2(a)gmail.com> Acked-by: Ping-Ke Shih <pkshih(a)realtek.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/aeeefad9-27c8-4506-a510-ef9a9a8731a4@gmail.com --- drivers/net/wireless/realtek/rtw88/mac.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw88/mac.c b/drivers/net/wireless/realtek/rtw88/mac.c index 298663b03580..0c1c1ff31085 100644 --- a/drivers/net/wireless/realtek/rtw88/mac.c +++ b/drivers/net/wireless/realtek/rtw88/mac.c @@ -309,6 +309,13 @@ static int rtw_mac_power_switch(struct rtw_dev *rtwdev, bool pwr_on) pwr_seq = pwr_on ? chip->pwr_on_seq : chip->pwr_off_seq; ret = rtw_pwr_seq_parser(rtwdev, pwr_seq); + if (pwr_on && rtw_hci_type(rtwdev) == RTW_HCI_TYPE_USB) { + if (chip->id == RTW_CHIP_TYPE_8822C || + chip->id == RTW_CHIP_TYPE_8822B || + chip->id == RTW_CHIP_TYPE_8821C) + rtw_write8_clr(rtwdev, REG_SYS_STATUS1 + 1, BIT(0)); + } + if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_SDIO) rtw_write32(rtwdev, REG_SDIO_HIMR, imr); -- 2.43.2

1 year, 3 months

2
3
0 0

[PATCHi 6.6 0/1] Cherrypick one more commit to fix iwlwifi crash on BE200

by Aaron Ma

Hi Levin, On Stable 6.6.23 kernel, iwlwifi crashed with the following error: [ 290.279712] ------------[ cut here ]------------ [ 290.279726] Invalid rxb from HW 0 [ 290.279816] WARNING: CPU: 19 PID: 477 at drivers/net/wireless/intel/iwlwifi/pcie/rx.c:1489 iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.279885] Modules linked in: snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_realtek snd_hda_codec_generic rfcomm nvme_fabrics ccm cmac algif_hash algif_skcipher af_alg bnep uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videodev btusb btrtl btintel btbcm btmtk videobuf2_common bluetooth mc ecdh_generic ecc joydev snd_soc_dmic intel_uncore_frequency intel_uncore_frequency_common snd_sof_pci_intel_mtl snd_sof_intel_hda_common x86_pkg_temp_thermal soundwire_intel intel_powerclamp soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp coretemp snd_sof snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core kvm_intel snd_soc_acpi_intel_match snd_soc_acpi soundwire_bus kvm snd_soc_core irqbypass snd_compress crct10dif_pclmul ac97_bus crc32_pclmul snd_pcm_dmaengine polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 iwlmvm snd_hda_intel sha256_ssse3 binfmt_misc sha1_ssse3 i915 [ 290.279973] snd_intel_dspcfg drm_buddy aesni_intel snd_intel_sdw_acpi ttm mac80211 crypto_simd processor_thermal_device_pci snd_hda_codec drm_display_helper spi_nor hid_multitouch processor_thermal_device cryptd think_lmi pmt_telemetry hid_generic libarc4 mtd intel_rapl_msr pmt_class iwlwifi firmware_attributes_class wmi_bmof snd_hda_core cec processor_thermal_rfim rapl snd_hwdep psmouse thinkpad_acpi input_leds rc_core mei_me snd_seq_midi ucsi_acpi processor_thermal_mbox intel_cstate intel_lpss_pci snd_seq_midi_event typec_ucsi processor_thermal_rapl nvram i2c_i801 intel_lpss xhci_pci drm_kms_helper spi_intel_pci ledtrig_audio cfg80211 snd_pcm e1000e thunderbolt serio_raw platform_profile mei i2c_smbus spi_intel typec idma64 xhci_pci_renesas i2c_algo_bit intel_vsec intel_rapl_common snd_rawmidi mac_hid snd_seq snd_seq_device snd_timer i2c_hid_acpi i2c_hid hid snd soundcore video int3403_thermal int340x_thermal_zone wmi acpi_tad acpi_pad intel_pmc_core intel_hid int3400_thermal pinctrl_meteorlake sparse_keymap [ 290.280076] acpi_thermal_rel sch_fq_codel msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables autofs4 [ 290.280097] CPU: 19 PID: 477 Comm: irq/182-iwlwifi Not tainted 6.6.23 #75 [ 290.280104] Hardware name: LENOVO 21ML0SIT12/21ML0SIT12, BIOS N47ET13W (1.02 ) 02/17/2024 [ 290.280108] RIP: 0010:iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280156] Code: 8b 8d 6c ff ff ff 4c 89 f2 4c 89 e6 4c 89 ef e8 4a f4 ff ff e9 08 fe ff ff 4d 89 ef 89 d6 48 c7 c7 c5 6c bf c0 e8 44 1d 36 fb <0f> 0b 4c 89 ff e8 1a 48 ff ff e9 9e fe ff ff 0f 1f 44 00 00 e9 f6 [ 290.280161] RSP: 0018:ffffc900004e0de8 EFLAGS: 00010246 [ 290.280167] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 290.280170] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 290.280173] RBP: ffffc900004e0e98 R08: 0000000000000000 R09: 0000000000000000 [ 290.280176] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88811dd27f88 [ 290.280179] R13: ffff888119ae8028 R14: ffff88812c4a0000 R15: ffff888119ae8028 [ 290.280182] FS: 0000000000000000(0000) GS:ffff8882214c0000(0000) knlGS:0000000000000000 [ 290.280187] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 290.280191] CR2: 00007f914800ba8c CR3: 000000020e83a005 CR4: 0000000000770ee0 [ 290.280195] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 290.280198] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 290.280201] PKRU: 55555554 [ 290.280204] Call Trace: [ 290.280208] <IRQ> [ 290.280214] ? show_regs+0x72/0x90 [ 290.280225] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280269] ? __warn+0x8d/0x160 [ 290.280278] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280324] ? report_bug+0x1bb/0x1d0 [ 290.280335] ? console_unlock+0x77/0x130 [ 290.280346] ? handle_bug+0x46/0x90 [ 290.280354] ? exc_invalid_op+0x19/0x80 [ 290.280360] ? asm_exc_invalid_op+0x1b/0x20 [ 290.280369] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280412] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280457] iwl_pcie_napi_poll_msix+0x30/0x100 [iwlwifi] [ 290.280500] ? try_to_wake_up+0x278/0x6c0 [ 290.280507] __napi_poll+0x30/0x1f0 [ 290.280515] net_rx_action+0x190/0x300 [ 290.280521] ? __irq_wake_thread+0x42/0x50 [ 290.280529] __do_softirq+0xda/0x330 [ 290.280533] ? handle_edge_irq+0xda/0x250 [ 290.280540] ? __pfx_irq_thread_fn+0x10/0x10 [ 290.280547] do_softirq.part.0+0x41/0x80 [ 290.280557] </IRQ> [ 290.280559] <TASK> [ 290.280562] __local_bh_enable_ip+0x72/0x80 [ 290.280570] iwl_pcie_irq_rx_msix_handler+0xd7/0x1c0 [iwlwifi] [ 290.280644] irq_thread_fn+0x25/0x70 [ 290.280653] irq_thread+0xea/0x1c0 [ 290.280660] ? __pfx_irq_thread_dtor+0x10/0x10 [ 290.280668] ? __pfx_irq_thread+0x10/0x10 [ 290.280675] kthread+0xf4/0x130 [ 290.280683] ? __pfx_kthread+0x10/0x10 [ 290.280690] ret_from_fork+0x43/0x70 [ 290.280697] ? __pfx_kthread+0x10/0x10 [ 290.280704] ret_from_fork_asm+0x1b/0x30 [ 290.280712] </TASK> [ 290.280715] ---[ end trace 0000000000000000 ]--- [ 290.281118] iwlwifi 0000:09:00.0: Microcode SW error detected. Restarting 0x0. Found the first bad commit c1c1039135c3 ("wifi: iwlwifi: increase number of RX buffers for EHT devices") Another commit should be along with it: commit 9f9797c7de18 ("wifi: iwlwifi: pcie: fix RB status reading") BugLink: https://bugs.launchpad.net/bugs/2058808 Johannes Berg (1): wifi: iwlwifi: pcie: fix RB status reading drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 8 ++++---- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 12 ++++-------- 3 files changed, 9 insertions(+), 13 deletions(-) -- 2.34.1

1 year, 3 months

2
2
0 0

Pull ASoC amd fixes into stable

by Luca Stefani

Hey stable folks, Can the following patches found in mainline [PATCH] ASoC: amd: yc: Revert "Fix non-functional mic on Lenovo 21J2" (861b341) [PATCH] ASoC: amd: yc: Revert "add new YC platform variant (0x63) support" (37bee18) be backported to linux-6.8.y? They're improperly assuming the 0x63 variant is part of the Yellow Carp family. This causes the microphone input device to not being properly probed on the device. Known broken devices: ThinkPad P16s Gen 2 (21K9CTO1WW) Thanks, Luca.

1 year, 3 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024