February 2025 - Linux-stable-mirror

[PATCH v4 1/1] xhci: Correctly handle last TRB of isoc TD on Etron xHCI host

by Kuangyi Chiang

Unplugging a USB3.0 webcam while streaming results in errors like this: [ 132.646387] xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 18 comp_code 13 [ 132.646446] xhci_hcd 0000:03:00.0: Looking for event-dma 000000002fdf8630 trb-start 000000002fdf8640 trb-end 000000002fdf8650 seg-start 000000002fdf8000 seg-end 000000002fdf8ff0 [ 132.646560] xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 18 comp_code 13 [ 132.646568] xhci_hcd 0000:03:00.0: Looking for event-dma 000000002fdf8660 trb-start 000000002fdf8670 trb-end 000000002fdf8670 seg-start 000000002fdf8000 seg-end 000000002fdf8ff0 If an error is detected while processing the last TRB of an isoc TD, the Etron xHC generates two transfer events for the TRB where the error was detected. The first event can be any sort of error (like USB Transaction or Babble Detected, etc), and the final event is Success. The xHCI driver will handle the TD after the first event and remove it from its internal list, and then print an "Transfer event TRB DMA ptr not part of current TD" error message after the final event. Commit 5372c65e1311 ("xhci: process isoc TD properly when there was a transaction error mid TD.") is designed to address isoc transaction errors, but unfortunately it doesn't account for this scenario. To work around this by reusing the logic that handles isoc transaction errors, but continuing to wait for the final event when this condition occurs. Sometimes we see the Stopped event after an error mid TD, this is a normal event for a pending TD and we can think of it as the final event we are waiting for. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in process_isoc_td(). Fixes: 5372c65e1311 ("xhci: process isoc TD properly when there was a transaction error mid TD.") Cc: <stable(a)vger.kernel.org> Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> --- drivers/usb/host/xhci-ring.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 965bffce301e..936fd9151ba8 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2452,8 +2452,10 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, switch (trb_comp_code) { case COMP_SUCCESS: /* Don't overwrite status if TD had an error, see xHCI 4.9.1 */ - if (td->error_mid_td) + if (td->error_mid_td) { + td->error_mid_td = false; break; + } if (remaining) { frame->status = short_framestatus; sum_trbs_for_length = true; @@ -2468,25 +2470,36 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, case COMP_BANDWIDTH_OVERRUN_ERROR: frame->status = -ECOMM; break; + case COMP_USB_TRANSACTION_ERROR: case COMP_BABBLE_DETECTED_ERROR: sum_trbs_for_length = true; fallthrough; case COMP_ISOCH_BUFFER_OVERRUN: frame->status = -EOVERFLOW; + if (trb_comp_code == COMP_USB_TRANSACTION_ERROR) + frame->status = -EPROTO; if (ep_trb != td->end_trb) td->error_mid_td = true; + else + td->error_mid_td = false; + + /* + * If an error is detected on the last TRB of the TD, + * wait for the final event. + */ + if ((xhci->quirks & XHCI_ETRON_HOST) && + td->urb->dev->speed >= USB_SPEED_SUPER && + ep_trb == td->end_trb) + td->error_mid_td = true; break; case COMP_INCOMPATIBLE_DEVICE_ERROR: case COMP_STALL_ERROR: frame->status = -EPROTO; break; - case COMP_USB_TRANSACTION_ERROR: - frame->status = -EPROTO; - sum_trbs_for_length = true; - if (ep_trb != td->end_trb) - td->error_mid_td = true; - break; case COMP_STOPPED: + /* Think of it as the final event if TD had an error */ + if (td->error_mid_td) + td->error_mid_td = false; sum_trbs_for_length = true; break; case COMP_STOPPED_SHORT_PACKET: @@ -2519,7 +2532,7 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, finish_td: /* Don't give back TD yet if we encountered an error mid TD */ - if (td->error_mid_td && ep_trb != td->end_trb) { + if (td->error_mid_td) { xhci_dbg(xhci, "Error mid isoc TD, wait for final completion event\n"); td->urb_length_set = true; return; -- 2.25.1

3 days, 11 hours

5
19
0 0

[PATCH v2 0/2] leds: rgb: leds-qcom-lpg: Fixes for Hi-Res PWMs

by Abel Vesa

The PWM Hi-Res allow configuring the PWM resolution from 8 bits PWM values up to 15 bits values. The current implementation loops through all possible resolutions (PWM sizes) on top of the already existing process of determining the prediv, exponent and refclk. The first issue is that the maximum value used for capping is wrongly hardcoded. The second issue is that it uses the wrong maximum possible PWM value for determining the best matched period. Fix both. Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Changes in v2: - Re-worded the commit to drop the details that are not important w.r.t. what the patch is fixing. - Added another patch which fixes the resolution used for determining best matched period and PWM config. - Link to v1: https://lore.kernel.org/r/20250220-leds-qcom-lpg-fix-max-pwm-on-hi-res-v1-1… --- Abel Vesa (2): leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs drivers/leds/rgb/leds-qcom-lpg.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- base-commit: 8433c776e1eb1371f5cd40b5fd3a61f9c7b7f3ad change-id: 20250220-leds-qcom-lpg-fix-max-pwm-on-hi-res-067e8782a79b Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

3 days, 12 hours

3
4
0 0

[PATCH v4 net-next] dpll: Add an assertion to check freq_supported_num

by Jiasheng Jiang

Since the driver is broken in the case that src->freq_supported is not NULL but src->freq_supported_num is 0, add an assertion for it. Signed-off-by: Jiasheng Jiang <jiashengjiangcool(a)gmail.com> --- Changelog: v3 -> v4: 1. Add return after WARN_ON(). v2 -> v3: 1. Add "net-next" to the subject. 2. Remove the "Fixes" tag and "Cc: stable". 3. Replace BUG_ON with WARN_ON. v1 -> v2: 1. Replace the check with an assertion. --- drivers/dpll/dpll_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c index 32019dc33cca..940c26b9dd53 100644 --- a/drivers/dpll/dpll_core.c +++ b/drivers/dpll/dpll_core.c @@ -443,8 +443,11 @@ static void dpll_pin_prop_free(struct dpll_pin_properties *prop) static int dpll_pin_prop_dup(const struct dpll_pin_properties *src, struct dpll_pin_properties *dst) { + if (WARN_ON(src->freq_supported && !src->freq_supported_num)) + return -EINVAL; + memcpy(dst, src, sizeof(*dst)); - if (src->freq_supported && src->freq_supported_num) { + if (src->freq_supported) { size_t freq_size = src->freq_supported_num * sizeof(*src->freq_supported); dst->freq_supported = kmemdup(src->freq_supported, -- 2.25.1

3 days, 12 hours

5
4
0 0

[PATCH] f2fs: fix the missing write pointer correction

by Jaegeuk Kim

If checkpoint was disabled, we missed to fix the write pointers. Cc: <stable(a)vger.kernel.org> Fixes: 1015035609e4 ("f2fs: fix changing cursegs if recovery fails on zoned device") Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> --- fs/f2fs/super.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index f5c69cc2de72..7a8fcc1e278c 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -4752,8 +4752,10 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent) if (err) goto free_meta; - if (unlikely(is_set_ckpt_flags(sbi, CP_DISABLED_FLAG))) + if (unlikely(is_set_ckpt_flags(sbi, CP_DISABLED_FLAG))) { + skip_recovery = true; goto reset_checkpoint; + } /* recover fsynced data */ if (!test_opt(sbi, DISABLE_ROLL_FORWARD) && -- 2.48.1.711.g2feabab25a-goog

3 days, 12 hours

3
2
0 0

Re: [PATCH v10 1/2] of: reserved_mem: Restruture how the reserved memory regions are processed

by Marco Felsch

Hi, On 24-10-08, Oreoluwa Babatunde wrote: > Reserved memory regions defined in the devicetree can be broken up into > two groups: > i) Statically-placed reserved memory regions > i.e. regions defined with a static start address and size using the > "reg" property. > ii) Dynamically-placed reserved memory regions. > i.e. regions defined by specifying an address range where they can be > placed in memory using the "alloc_ranges" and "size" properties. > > These regions are processed and set aside at boot time. > This is done in two stages as seen below: > > Stage 1: > At this stage, fdt_scan_reserved_mem() scans through the child nodes of > the reserved_memory node using the flattened devicetree and does the > following: > > 1) If the node represents a statically-placed reserved memory region, > i.e. if it is defined using the "reg" property: > - Call memblock_reserve() or memblock_mark_nomap() as needed. > - Add the information for that region into the reserved_mem array > using fdt_reserved_mem_save_node(). > i.e. fdt_reserved_mem_save_node(node, name, base, size). > > 2) If the node represents a dynamically-placed reserved memory region, > i.e. if it is defined using "alloc-ranges" and "size" properties: > - Add the information for that region to the reserved_mem array with > the starting address and size set to 0. > i.e. fdt_reserved_mem_save_node(node, name, 0, 0). > Note: This region is saved to the array with a starting address of 0 > because a starting address is not yet allocated for it. > > Stage 2: > After iterating through all the reserved memory nodes and storing their > relevant information in the reserved_mem array,fdt_init_reserved_mem() is > called and does the following: > > 1) For statically-placed reserved memory regions: > - Call the region specific init function using > __reserved_mem_init_node(). > 2) For dynamically-placed reserved memory regions: > - Call __reserved_mem_alloc_size() which is used to allocate memory > for each of these regions, and mark them as nomap if they have the > nomap property specified in the DT. > - Call the region specific init function. > > The current size of the resvered_mem array is 64 as is defined by > MAX_RESERVED_REGIONS. This means that there is a limitation of 64 for > how many reserved memory regions can be specified on a system. > As systems continue to grow more and more complex, the number of > reserved memory regions needed are also growing and are starting to hit > this 64 count limit, hence the need to make the reserved_mem array > dynamically sized (i.e. dynamically allocating memory for the > reserved_mem array using membock_alloc_*). > > On architectures such as arm64, memory allocated using memblock is > writable only after the page tables have been setup. This means that if > the reserved_mem array is going to be dynamically allocated, it needs to > happen after the page tables have been setup, not before. > > Since the reserved memory regions are currently being processed and > added to the array before the page tables are setup, there is a need to > change the order in which some of the processing is done to allow for > the reserved_mem array to be dynamically sized. > > It is possible to process the statically-placed reserved memory regions > without needing to store them in the reserved_mem array until after the > page tables have been setup because all the information stored in the > array is readily available in the devicetree and can be referenced at > any time. > Dynamically-placed reserved memory regions on the other hand get > assigned a start address only at runtime, and hence need a place to be > stored once they are allocated since there is no other referrence to the > start address for these regions. > > Hence this patch changes the processing order of the reserved memory > regions in the following ways: > > Step 1: > fdt_scan_reserved_mem() scans through the child nodes of > the reserved_memory node using the flattened devicetree and does the > following: > > 1) If the node represents a statically-placed reserved memory region, > i.e. if it is defined using the "reg" property: > - Call memblock_reserve() or memblock_mark_nomap() as needed. > > 2) If the node represents a dynamically-placed reserved memory region, > i.e. if it is defined using "alloc-ranges" and "size" properties: > - Call __reserved_mem_alloc_size() which will: > i) Allocate memory for the reserved region and call > memblock_mark_nomap() as needed. > ii) Call the region specific initialization function using > fdt_init_reserved_mem_node(). > iii) Save the region information in the reserved_mem array using > fdt_reserved_mem_save_node(). > > Step 2: > 1) This stage of the reserved memory processing is now only used to add > the statically-placed reserved memory regions into the reserved_mem > array using fdt_scan_reserved_mem_reg_nodes(), as well as call their > region specific initialization functions. > > 2) This step has also been moved to be after the page tables are > setup. Moving this will allow us to replace the reserved_mem > array with a dynamically sized array before storing the rest of > these regions. > > Signed-off-by: Oreoluwa Babatunde <quic_obabatun(a)quicinc.com> > --- > drivers/of/fdt.c | 5 +- > drivers/of/of_private.h | 3 +- > drivers/of/of_reserved_mem.c | 168 ++++++++++++++++++++++++----------- > 3 files changed, 122 insertions(+), 54 deletions(-) this patch got into stable kernel 6.12.13++ as part of Stable-dep-of. The stable kernel commit is: 9a0fe62f93ede02c27aaca81112af1e59c8c0979. With the patch applied I see that the cma area pool is misplaced which cause my 4G device to fail to activate the cma pool. Below are some logs: *** Good case (6.12) root@test:~# dmesg|grep -i cma [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x0000000044200000..0x00000000541fffff (262144 KiB) map reusable linux,cma [ 0.056915] Memory: 3695024K/4194304K available (15552K kernel code, 2510K rwdata, 5992K rodata, 6016K init, 489K bss, 231772K reserved, 262144K cma-reserved) *** Bad (6.12.16) root@test:~# dmesg|grep -i cma [ 0.000000] Reserved memory: created CMA memory pool at 0x00000000f2000000, size 256 MiB [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x00000000f2000000..0x0000000101ffffff (262144 KiB) map reusable linux,cma [ 0.056968] Memory: 3694896K/4194304K available (15616K kernel code, 2512K rwdata, 6012K rodata, 6080K init, 491K bss, 231900K reserved, 262144K cma-reserved) [ 0.116920] cma: CMA area linux,cma could not be activated *** Good (6.12.16, revert 9a0fe62f93ed) root@test:~# dmesg|grep -i cma [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x0000000044200000..0x00000000541fffff (262144 KiB) map reusable linux,cma [ 0.060976] Memory: 3694896K/4194304K available (15616K kernel code, 2512K rwdata, 6012K rodata, 6080K init, 491K bss, 231900K reserved, 262144K cma-reserved) Below is our reserved-memory dts node: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; linux,cma { compatible = "shared-dma-pool"; reusable; /* * The CMA area must be in the lower 32-bit address range. */ alloc-ranges = <0x0 0x42000000 0 0xc0000000>; size = <0x0 0x10000000>; alignment = <0 0x2000>; linux,cma-default; }; optee-core@40000000 { reg = <0 0x40000000 0 0x1e00000>; no-map; }; optee-shm@41e00000 { reg = <0 0x41e00000 0 0x200000>; no-map; }; m7_reserved: m7@80000000 { reg = <0 0x80000000 0 0x1000000>; no-map; }; vdev0vring0: vdev0vring0@55000000 { reg = <0 0x55000000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@55008000 { reg = <0 0x55008000 0 0x8000>; no-map; }; rsc_table: rsc-table@550ff000 { reg = <0 0x550ff000 0 0x1000>; no-map; }; ram_console_buffer: ram-console-buffer@55100000 { reg = <0 0x55100000 0 0x1000>; no-map; }; vdev0buffer: vdev0buffer@55400000 { compatible = "shared-dma-pool"; reg = <0 0x55400000 0 0x100000>; no-map; }; }; My current workaround is to revert commit 9a0fe62f93ed and the dep-chain: 2d1d620ff27b444 8de4e5a92282. But I would like to get a proper solution without having revert commits in my downstream patchstack. Regards, Marco

3 days, 13 hours

2
3
0 0

[PATCH] leds: rgb: leds-qcom-lpg: Fix pwm resolution for Hi-Res PWMs

by Abel Vesa

Currently, for the high resolution PWMs, the resolution, clock, pre-divider and exponent are being selected based on period. Basically, the implementation loops over each one of these and tries to find the closest (higher) period based on the following formula: period * refclk prediv_exp = log2 ------------------------------------- NSEC_PER_SEC * pre_div * resolution Since the resolution is power of 2, the actual period resulting is usually higher than what the resolution allows. That's why the duty cycle requested needs to be capped to the maximum value allowed by the resolution (known as PWM size). Here is an example of how this can happen: For a requested period of 5000000, the best clock is 19.2MHz, the best prediv is 5, the best exponent is 6 and the best resolution is 256. Then, the pwm value is determined based on requested period and duty cycle, best prediv, best exponent and best clock, using the following formula: duty * refclk pwm_value = ---------------------------------------------- NSEC_PER_SEC * prediv * (1 << prediv_exp) So in this specific scenario: (5000000 * 19200000) / (1000000000 * 5 * (1 << 64)) = 300 With a resolution of 8 bits, this pwm value obviously goes over. Therefore, the max pwm value allowed needs to be 255. If not, the PMIC internal logic will only value that is under the set PWM size, resulting in a wrapped around PWM value. This has been observed on Lenovo Thinkpad T14s Gen6 (LCD panel version) which uses one of the PMK8550 to control the LCD backlight. Fix the value of the PWM by capping to a max based on the chosen resolution (PWM size). Cc: stable(a)vger.kernel.org # 6.4 Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Note: This fix is blocking backlight support on Lenovo Thinkpad T14s Gen6 (LCD version), for which I have patches ready to send once this patch is agreed on (review) and merged. --- drivers/leds/rgb/leds-qcom-lpg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c index f3c9ef2bfa572f9ee86c8b8aa37deb8231965490..146cd9b447787bf170310321e939022dfb176e9f 100644 --- a/drivers/leds/rgb/leds-qcom-lpg.c +++ b/drivers/leds/rgb/leds-qcom-lpg.c @@ -529,7 +529,7 @@ static void lpg_calc_duty(struct lpg_channel *chan, uint64_t duty) unsigned int clk_rate; if (chan->subtype == LPG_SUBTYPE_HI_RES_PWM) { - max = LPG_RESOLUTION_15BIT - 1; + max = BIT(lpg_pwm_resolution_hi_res[chan->pwm_resolution_sel]) - 1; clk_rate = lpg_clk_rates_hi_res[chan->clk_sel]; } else { max = LPG_RESOLUTION_9BIT - 1; --- base-commit: 50a0c754714aa3ea0b0e62f3765eb666a1579f24 change-id: 20250220-leds-qcom-lpg-fix-max-pwm-on-hi-res-067e8782a79b Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

3 days, 13 hours

5
15
0 0

[for-linus][PATCH 3/3] ftrace: Avoid potential division by zero in function_stat_show()

by Steven Rostedt

From: Nikolay Kuratov <kniv(a)yandex-team.ru> Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case. For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier. Cc: stable(a)vger.kernel.org Cc: Wen Yang <wenyang(a)linux.alibaba.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Link: https://lore.kernel.org/20250206090156.1561783-1-kniv@yandex-team.ru Fixes: e31f7939c1c27 ("ftrace: Avoid potential division by zero in function profiler") Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ftrace.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 6b0c25761ccb..fc88e0688daf 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -540,6 +540,7 @@ static int function_stat_show(struct seq_file *m, void *v) static struct trace_seq s; unsigned long long avg; unsigned long long stddev; + unsigned long long stddev_denom; #endif guard(mutex)(&ftrace_profile_lock); @@ -559,23 +560,19 @@ static int function_stat_show(struct seq_file *m, void *v) #ifdef CONFIG_FUNCTION_GRAPH_TRACER seq_puts(m, " "); - /* Sample standard deviation (s^2) */ - if (rec->counter <= 1) - stddev = 0; - else { - /* - * Apply Welford's method: - * s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2) - */ + /* + * Variance formula: + * s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2) + * Maybe Welford's method is better here? + * Divide only by 1000 for ns^2 -> us^2 conversion. + * trace_print_graph_duration will divide by 1000 again. + */ + stddev = 0; + stddev_denom = rec->counter * (rec->counter - 1) * 1000; + if (stddev_denom) { stddev = rec->counter * rec->time_squared - rec->time * rec->time; - - /* - * Divide only 1000 for ns^2 -> us^2 conversion. - * trace_print_graph_duration will divide 1000 again. - */ - stddev = div64_ul(stddev, - rec->counter * (rec->counter - 1) * 1000); + stddev = div64_ul(stddev, stddev_denom); } trace_seq_init(&s); -- 2.47.2

3 days, 13 hours

1
0
0 0

[for-linus][PATCH 1/3] tracing: Fix bad hist from corrupting named_triggers list

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> The following commands causes a crash: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=common_pid' > trigger Because the following occurs: event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg; [..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!) [..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- NEVER gets removed! } } } } [..] kfree(data); <<<-- frees item but it is still on list The next time a hist with name is registered, it causes an u-a-f bug and the kernel can crash. Move the code around such that if event_trigger_register() succeeds, the next thing called is hist_trigger_enable() which adds it to the list. A bunch of actions is called if get_named_trigger_data() returns false. But that doesn't need to be called after event_trigger_register(), so it can be moved up, allowing event_trigger_register() to be called just before hist_trigger_enable() keeping them together and allowing the file->triggers to be properly populated. Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Link: https://lore.kernel.org/20250227163944.1c37f85f@gandalf.local.home Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers") Reported-by: Tomas Glozar <tglozar(a)redhat.com> Tested-by: Tomas Glozar <tglozar(a)redhat.com> Reviewed-by: Tom Zanussi <zanussi(a)kernel.org> Closes: https://lore.kernel.org/all/CAP4=nvTsxjckSBTz=Oe_UYh8keD9_sZC4i++4h72mJLic4… Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/trace_events_hist.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index 261163b00137..ad7419e24055 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -6724,27 +6724,27 @@ static int event_hist_trigger_parse(struct event_command *cmd_ops, if (existing_hist_update_only(glob, trigger_data, file)) goto out_free; - ret = event_trigger_register(cmd_ops, file, glob, trigger_data); - if (ret < 0) - goto out_free; + if (!get_named_trigger_data(trigger_data)) { - if (get_named_trigger_data(trigger_data)) - goto enable; + ret = create_actions(hist_data); + if (ret) + goto out_free; - ret = create_actions(hist_data); - if (ret) - goto out_unreg; + if (has_hist_vars(hist_data) || hist_data->n_var_refs) { + ret = save_hist_vars(hist_data); + if (ret) + goto out_free; + } - if (has_hist_vars(hist_data) || hist_data->n_var_refs) { - ret = save_hist_vars(hist_data); + ret = tracing_map_init(hist_data->map); if (ret) - goto out_unreg; + goto out_free; } - ret = tracing_map_init(hist_data->map); - if (ret) - goto out_unreg; -enable: + ret = event_trigger_register(cmd_ops, file, glob, trigger_data); + if (ret < 0) + goto out_free; + ret = hist_trigger_enable(trigger_data, file); if (ret) goto out_unreg; -- 2.47.2

3 days, 13 hours

1
0
0 0

[PATCH v3] usb: hub: lack of clearing xHC resources

by Pawel Laszczak

The xHC resources allocated for USB devices are not released in correct order after resuming in case when while suspend device was reconnected. This issue has been detected during the fallowing scenario: - connect hub HS to root port - connect LS/FS device to hub port - wait for enumeration to finish - force host to suspend - reconnect hub attached to root port - wake host For this scenario during enumeration of USB LS/FS device the Cadence xHC reports completion error code for xHC commands because the xHC resources used for devices has not been properly released. XHCI specification doesn't mention that device can be reset in any order so, we should not treat this issue as Cadence xHC controller bug. Similar as during disconnecting in this case the device resources should be cleared starting form the last usb device in tree toward the root hub. To fix this issue usbcore driver should call hcd->driver->reset_device for all USB devices connected to hub which was reconnected while suspending. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: <stable(a)vger.kernel.org> Signed-off-by: Pawel Laszczak <pawell(a)cadence.com> --- Changelog: v3: - Changed patch title - Corrected typo - Moved hub_hc_release_resources above mutex_lock(hcd->address0_mutex) v2: - Replaced disconnection procedure with releasing only the xHC resources drivers/usb/core/hub.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index a76bb50b6202..dcba4281ea48 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -6065,6 +6065,36 @@ void usb_hub_cleanup(void) usb_deregister(&hub_driver); } /* usb_hub_cleanup() */ +/** + * hub_hc_release_resources - clear resources used by host controller + * @udev: pointer to device being released + * + * Context: task context, might sleep + * + * Function releases the host controller resources in correct order before + * making any operation on resuming usb device. The host controller resources + * allocated for devices in tree should be released starting from the last + * usb device in tree toward the root hub. This function is used only during + * resuming device when usb device require reinitialization – that is, when + * flag udev->reset_resume is set. + * + * This call is synchronous, and may not be used in an interrupt context. + */ +static void hub_hc_release_resources(struct usb_device *udev) +{ + struct usb_hub *hub = usb_hub_to_struct_hub(udev); + struct usb_hcd *hcd = bus_to_hcd(udev->bus); + int i; + + /* Release up resources for all children before this device */ + for (i = 0; i < udev->maxchild; i++) + if (hub->ports[i]->child) + hub_hc_release_resources(hub->ports[i]->child); + + if (hcd->driver->reset_device) + hcd->driver->reset_device(hcd, udev); +} + /** * usb_reset_and_verify_device - perform a USB port reset to reinitialize a device * @udev: device to reset (not in SUSPENDED or NOTATTACHED state) @@ -6129,6 +6159,9 @@ static int usb_reset_and_verify_device(struct usb_device *udev) bos = udev->bos; udev->bos = NULL; + if (udev->reset_resume) + hub_hc_release_resources(udev); + mutex_lock(hcd->address0_mutex); for (i = 0; i < PORT_INIT_TRIES; ++i) { -- 2.43.0

3 days, 14 hours

2
1
0 0

v6.6.78 regression: rtla/timerlat_top: Set OSNOISE_WORKLOAD for kernel threads

by Jan Kundrát

Hi there, I cannot build the `rtla` tool in the stable branch, version v6.6.80. The root cause appears to be commit 41955b6c268154f81e34f9b61cf8156eec0730c0 which first appeared in v6.6.78. Here's how the build failure looks like through Buildroot: src/timerlat_hist.c: In function â€timerlat_hist_apply_configâ€™: src/timerlat_hist.c:908:60: error: â€struct timerlat_hist_paramsâ€™ has no member named â€kernel_workloadâ€™ 908 | retval = osnoise_set_workload(tool->context, params->kernel_workload); | ^~ make[3]: *** [<builtin>: src/timerlat_hist.o] Error 1 A quick grep shows that that symbol is referenced, but not defined anywhere: ~/work/prog/linux-kernel[cesnet/2025-02-28] $ git grep kernel_workload tools/tracing/rtla/src/timerlat_hist.c: retval = osnoise_set_workload(tool->context, params->kernel_workload); tools/tracing/rtla/src/timerlat_top.c: retval = osnoise_set_workload(top->context, params->kernel_workload); Maybe some prerequisite patch is missing? With kind regards, Jan

3 days, 16 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025