March 2024 - Linux-stable-mirror

[PATCH v3 1/2] media: ov2680: Clear the 'ret' variable on success

by Fabio Estevam

From: Fabio Estevam <festevam(a)denx.de> Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") even when the correct 'link-frequencies' property is passed in the devicetree, the driver fails to probe: ov2680 1-0036: probe with driver ov2680 failed with error -22 The reason is that the variable 'ret' may contain the -EINVAL value from a previous assignment: ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &rate); Fix the problem by clearing 'ret' on the successful path. Tested on imx7s-warp board with the following devicetree: port { ov2680_to_mipi: endpoint { remote-endpoint = <&mipi_from_sensor>; clock-lanes = <0>; data-lanes = <1>; link-frequencies = /bits/ 64 <330000000>; }; }; Cc: stable(a)vger.kernel.org Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") Suggested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Fabio Estevam <festevam(a)denx.de> Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes since v2: - Collected Hans' Reviewed-by tag. drivers/media/i2c/ov2680.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c index 39d321e2b7f9..3e3b7c2b492c 100644 --- a/drivers/media/i2c/ov2680.c +++ b/drivers/media/i2c/ov2680.c @@ -1135,6 +1135,7 @@ static int ov2680_parse_dt(struct ov2680_dev *sensor) goto out_free_bus_cfg; } + ret = 0; out_free_bus_cfg: v4l2_fwnode_endpoint_free(&bus_cfg); return ret; -- 2.34.1

1 year, 7 months

2
2
0 0

FAILED: Patch "ACPI: CPPC: Use access_width over bit_width for system memory accesses" failed to apply to 5.15-stable tree

by Sasha Levin

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>. Thanks, Sasha ------------------ original commit in Linus's tree ------------------ From 2f4a4d63a193be6fd530d180bb13c3592052904c Mon Sep 17 00:00:00 2001 From: Jarred White <jarredwhite(a)linux.microsoft.com> Date: Fri, 1 Mar 2024 11:25:59 -0800 Subject: [PATCH] ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. Signed-off-by: Jarred White <jarredwhite(a)linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha(a)linux.microsoft.com> Cc: 5.15+ <stable(a)vger.kernel.org> # 5.15+ [ rjw: Subject and changelog edits, comment adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> --- drivers/acpi/cppc_acpi.c | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index d155a86a86148..b954ce3638a9c 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -166,6 +166,13 @@ show_cppc_data(cppc_get_perf_caps, cppc_perf_caps, nominal_freq); show_cppc_data(cppc_get_perf_ctrs, cppc_perf_fb_ctrs, reference_perf); show_cppc_data(cppc_get_perf_ctrs, cppc_perf_fb_ctrs, wraparound_time); +/* Check for valid access_width, otherwise, fallback to using bit_width */ +#define GET_BIT_WIDTH(reg) ((reg)->access_width ? (8 << ((reg)->access_width - 1)) : (reg)->bit_width) + +/* Shift and apply the mask for CPC reads/writes */ +#define MASK_VAL(reg, val) ((val) >> ((reg)->bit_offset & \ + GENMASK(((reg)->bit_width), 0))) + static ssize_t show_feedback_ctrs(struct kobject *kobj, struct kobj_attribute *attr, char *buf) { @@ -780,6 +787,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) } else if (gas_t->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { if (gas_t->address) { void __iomem *addr; + size_t access_width; if (!osc_cpc_flexible_adr_space_confirmed) { pr_debug("Flexible address space capability not supported\n"); @@ -787,7 +795,8 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) goto out_free; } - addr = ioremap(gas_t->address, gas_t->bit_width/8); + access_width = GET_BIT_WIDTH(gas_t) / 8; + addr = ioremap(gas_t->address, access_width); if (!addr) goto out_free; cpc_ptr->cpc_regs[i-2].sys_mem_vaddr = addr; @@ -983,6 +992,7 @@ int __weak cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val) static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) { void __iomem *vaddr = NULL; + int size; int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); struct cpc_reg *reg = &reg_res->cpc_entry.reg; @@ -994,7 +1004,7 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) *val = 0; if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { - u32 width = 8 << (reg->access_width - 1); + u32 width = GET_BIT_WIDTH(reg); u32 val_u32; acpi_status status; @@ -1018,7 +1028,9 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) return acpi_os_read_memory((acpi_physical_address)reg->address, val, reg->bit_width); - switch (reg->bit_width) { + size = GET_BIT_WIDTH(reg); + + switch (size) { case 8: *val = readb_relaxed(vaddr); break; @@ -1037,18 +1049,22 @@ static int cpc_read(int cpu, struct cpc_register_resource *reg_res, u64 *val) return -EFAULT; } + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) + *val = MASK_VAL(reg, *val); + return 0; } static int cpc_write(int cpu, struct cpc_register_resource *reg_res, u64 val) { int ret_val = 0; + int size; void __iomem *vaddr = NULL; int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpu); struct cpc_reg *reg = &reg_res->cpc_entry.reg; if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { - u32 width = 8 << (reg->access_width - 1); + u32 width = GET_BIT_WIDTH(reg); acpi_status status; status = acpi_os_write_port((acpi_io_address)reg->address, @@ -1070,7 +1086,12 @@ static int cpc_write(int cpu, struct cpc_register_resource *reg_res, u64 val) return acpi_os_write_memory((acpi_physical_address)reg->address, val, reg->bit_width); - switch (reg->bit_width) { + size = GET_BIT_WIDTH(reg); + + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) + val = MASK_VAL(reg, val); + + switch (size) { case 8: writeb_relaxed(val, vaddr); break; -- 2.43.0

1 year, 7 months

3
2
0 0

[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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024