October 2025 - Linux-stable-mirror

[PATCH] drm/mediatek: Fix device node reference leak in mtk_dp_dt_parse()

by Miaoqian Lin

The function mtk_dp_dt_parse() calls of_graph_get_endpoint_by_regs() to get the endpoint device node, but fails to call of_node_put() to release the reference when the function returns. This results in a device node reference leak. Fix this by adding the missing of_node_put() call before returning from the function. Found via static analysis and code review. Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/mediatek/mtk_dp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c index bef6eeb30d3e..b0b1e158600f 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -2087,6 +2087,7 @@ static int mtk_dp_dt_parse(struct mtk_dp *mtk_dp, endpoint = of_graph_get_endpoint_by_regs(pdev->dev.of_node, 1, -1); len = of_property_count_elems_of_size(endpoint, "data-lanes", sizeof(u32)); + of_node_put(endpoint); if (len < 0 || len > 4 || len == 3) { dev_err(dev, "invalid data lane size: %d\n", len); return -EINVAL; -- 2.39.5 (Apple Git-154)

2 days, 15 hours

3
2
0 0

[PATCH v1 1/2] ALSA: hda/tas2781: fix speaker id retrieval for multiple probes

by Antheas Kapenekakis

Currently, on ASUS projects, the TAS2781 codec attaches the speaker GPIO to the first tasdevice_priv instance using devm. This causes tas2781_read_acpi to fail on subsequent probes since the GPIO is already managed by the first device. This causes a failure on Xbox Ally X, because it has two amplifiers, and prevents us from quirking both the Xbox Ally and Xbox Ally X in the realtek codec driver. It is unnecessary to attach the GPIO to a device as it is static. Therefore, instead of attaching it and then reading it when loading the firmware, read its value directly in tas2781_read_acpi and store it in the private data structure. Then, make reading the value non-fatal so that ASUS projects that miss a speaker pin can still work, perhaps using fallback firmware. Fixes: 4e7035a75da9 ("ALSA: hda/tas2781: Add speaker id check for ASUS projects") Cc: stable(a)vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis <lkml(a)antheas.dev> --- include/sound/tas2781.h | 2 +- .../hda/codecs/side-codecs/tas2781_hda_i2c.c | 44 +++++++++++-------- 2 files changed, 26 insertions(+), 20 deletions(-) diff --git a/include/sound/tas2781.h b/include/sound/tas2781.h index 0fbcdb15c74b..29d15ba65f04 100644 --- a/include/sound/tas2781.h +++ b/include/sound/tas2781.h @@ -197,7 +197,6 @@ struct tasdevice_priv { struct acoustic_data acou_data; #endif struct tasdevice_fw *fmw; - struct gpio_desc *speaker_id; struct gpio_desc *reset; struct mutex codec_lock; struct regmap *regmap; @@ -215,6 +214,7 @@ struct tasdevice_priv { unsigned int magic_num; unsigned int chip_id; unsigned int sysclk; + int speaker_id; int irq; int cur_prog; diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index 0357401a6023..c8619995b1d7 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -87,6 +87,7 @@ static const struct acpi_gpio_mapping tas2781_speaker_id_gpios[] = { static int tas2781_read_acpi(struct tasdevice_priv *p, const char *hid) { + struct gpio_desc *speaker_id; struct acpi_device *adev; struct device *physdev; LIST_HEAD(resources); @@ -119,19 +120,31 @@ static int tas2781_read_acpi(struct tasdevice_priv *p, const char *hid) /* Speaker id was needed for ASUS projects. */ ret = kstrtou32(sub, 16, &subid); if (!ret && upper_16_bits(subid) == PCI_VENDOR_ID_ASUSTEK) { - ret = devm_acpi_dev_add_driver_gpios(p->dev, - tas2781_speaker_id_gpios); - if (ret < 0) + ret = acpi_dev_add_driver_gpios(adev, tas2781_speaker_id_gpios); + if (ret < 0) { dev_err(p->dev, "Failed to add driver gpio %d.\n", ret); - p->speaker_id = devm_gpiod_get(p->dev, "speakerid", GPIOD_IN); - if (IS_ERR(p->speaker_id)) { - dev_err(p->dev, "Failed to get Speaker id.\n"); - ret = PTR_ERR(p->speaker_id); - goto err; + p->speaker_id = -1; + goto end_2563; + } + + speaker_id = fwnode_gpiod_get_index(acpi_fwnode_handle(adev), + "speakerid", 0, GPIOD_IN, NULL); + if (!IS_ERR(speaker_id)) { + p->speaker_id = gpiod_get_value_cansleep(speaker_id); + dev_dbg(p->dev, "Got speaker id gpio from ACPI: %d.\n", + p->speaker_id); + gpiod_put(speaker_id); + } else { + p->speaker_id = -1; + ret = PTR_ERR(speaker_id); + dev_err(p->dev, "Get speaker id gpio failed %d.\n", + ret); } + + acpi_dev_remove_driver_gpios(adev); } else { - p->speaker_id = NULL; + p->speaker_id = -1; } end_2563: @@ -432,23 +445,16 @@ static void tasdevice_dspfw_init(void *context) struct tas2781_hda *tas_hda = dev_get_drvdata(tas_priv->dev); struct tas2781_hda_i2c_priv *hda_priv = tas_hda->hda_priv; struct hda_codec *codec = tas_priv->codec; - int ret, spk_id; + int ret; tasdevice_dsp_remove(tas_priv); tas_priv->fw_state = TASDEVICE_DSP_FW_PENDING; - if (tas_priv->speaker_id != NULL) { - // Speaker id need to be checked for ASUS only. - spk_id = gpiod_get_value(tas_priv->speaker_id); - if (spk_id < 0) { - // Speaker id is not valid, use default. - dev_dbg(tas_priv->dev, "Wrong spk_id = %d\n", spk_id); - spk_id = 0; - } + if (tas_priv->speaker_id >= 0) { snprintf(tas_priv->coef_binaryname, sizeof(tas_priv->coef_binaryname), "TAS2XXX%04X%d.bin", lower_16_bits(codec->core.subsystem_id), - spk_id); + tas_priv->speaker_id); } else { snprintf(tas_priv->coef_binaryname, sizeof(tas_priv->coef_binaryname), base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada -- 2.51.1

3 days, 14 hours

4
11
0 0

[PATCH] media: iris: Fix ffmpeg corrupted frame error

by Vishnu Reddy

When the ffmpeg decoder is running, the driver receives the V4L2_BUF_FLAG_KEYFRAME flag in the input buffer. The driver then forwards this flag information to the firmware. The firmware, in turn, copies the input buffer flags directly into the output buffer flags. Upon receiving the output buffer from the firmware, the driver observes that the buffer contains the HFI_BUFFERFLAG_DATACORRUPT flag. The root cause is that both V4L2_BUF_FLAG_KEYFRAME and HFI_BUFFERFLAG_DATACORRUPT are the same value. As a result, the driver incorrectly interprets the output frame as corrupted, even though the frame is actually valid. This misinterpretation causes the driver to report an error and skip good frames, leading to missing frames in the final video output and triggering ffmpeg's "corrupt decoded frame" error. To resolve this issue, the input buffer flags should not be sent to the firmware during decoding, since the firmware does not require this information. Fixes: 17f2a485ca67 ("media: iris: implement vb2 ops for buf_queue and firmware response") Cc: stable(a)vger.kernel.org Signed-off-by: Vishnu Reddy <quic_bvisredd(a)quicinc.com> --- drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c index e1788c266bb1..4de03f31eaf3 100644 --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c @@ -282,7 +282,7 @@ static int iris_hfi_gen1_queue_input_buffer(struct iris_inst *inst, struct iris_ com_ip_pkt.shdr.session_id = inst->session_id; com_ip_pkt.time_stamp_hi = upper_32_bits(buf->timestamp); com_ip_pkt.time_stamp_lo = lower_32_bits(buf->timestamp); - com_ip_pkt.flags = buf->flags; + com_ip_pkt.flags = 0; com_ip_pkt.mark_target = 0; com_ip_pkt.mark_data = 0; com_ip_pkt.offset = buf->data_offset; -- 2.34.1

3 days, 16 hours

4
4
0 0

[PATCH v6 01/18] kasan: Unpoison pcpu chunks with base address tag

by Maciej Wieczor-Retman

From: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> The problem presented here is related to NUMA systems and tag-based KASAN modes - software and hardware ones. It can be explained in the following points: 1. There can be more than one virtual memory chunk. 2. Chunk's base address has a tag. 3. The base address points at the first chunk and thus inherits the tag of the first chunk. 4. The subsequent chunks will be accessed with the tag from the first chunk. 5. Thus, the subsequent chunks need to have their tag set to match that of the first chunk. Refactor code by moving it into a helper in preparation for the actual fix. Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS") Cc: <stable(a)vger.kernel.org> # 6.1+ Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman(a)intel.com> Tested-by: Baoquan He <bhe(a)redhat.com> --- Changelog v6: - Add Baoquan's tested-by tag. - Move patch to the beginning of the series as it is a fix. - Move the refactored code to tags.c because both software and hardware modes compile it. - Add fixes tag. Changelog v4: - Redo the patch message numbered list. - Do the refactoring in this patch and move additions to the next new one. Changelog v3: - Remove last version of this patch that just resets the tag on base_addr and add this patch that unpoisons all areas with the same tag instead. include/linux/kasan.h | 10 ++++++++++ mm/kasan/tags.c | 11 +++++++++++ mm/vmalloc.c | 4 +--- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d12e1a5f5a9a..b00849ea8ffd 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -614,6 +614,13 @@ static __always_inline void kasan_poison_vmalloc(const void *start, __kasan_poison_vmalloc(start, size); } +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms); +static __always_inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ + if (kasan_enabled()) + __kasan_unpoison_vmap_areas(vms, nr_vms); +} + #else /* CONFIG_KASAN_VMALLOC */ static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -638,6 +645,9 @@ static inline void *kasan_unpoison_vmalloc(const void *start, static inline void kasan_poison_vmalloc(const void *start, unsigned long size) { } +static inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ } + #endif /* CONFIG_KASAN_VMALLOC */ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c index b9f31293622b..ecc17c7c675a 100644 --- a/mm/kasan/tags.c +++ b/mm/kasan/tags.c @@ -18,6 +18,7 @@ #include <linux/static_key.h> #include <linux/string.h> #include <linux/types.h> +#include <linux/vmalloc.h> #include "kasan.h" #include "../slab.h" @@ -146,3 +147,13 @@ void __kasan_save_free_info(struct kmem_cache *cache, void *object) { save_stack_info(cache, object, 0, true); } + +void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms) +{ + int area; + + for (area = 0 ; area < nr_vms ; area++) { + kasan_poison(vms[area]->addr, vms[area]->size, + arch_kasan_get_tag(vms[area]->addr), false); + } +} diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 798b2ed21e46..934c8bfbcebf 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4870,9 +4870,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets, * With hardware tag-based KASAN, marking is skipped for * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc(). */ - for (area = 0; area < nr_vms; area++) - vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr, - vms[area]->size, KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vmap_areas(vms, nr_vms); kfree(vas); return vms; -- 2.51.0

4 days, 3 hours

3
2
0 0

FAILED: patch "[PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x e84cb860ac3ce67ec6ecc364433fd5b412c448bc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102646-unwary-premises-4a2c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e84cb860ac3ce67ec6ecc364433fd5b412c448bc Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:26 +0200 Subject: [PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR The special C-flag case expects the ADD_ADDR to be received when switching to 'fully-established'. But for various reasons, the ADD_ADDR could be sent after the "4th ACK", and the special case doesn't work. On NIPA, the new test validating this special case for the C-flag failed a few times, e.g. 102 default limits, server deny join id 0 syn rx [FAIL] got 0 JOIN[s] syn rx expected 2 Server ns stats (...) MPTcpExtAddAddrTx 1 MPTcpExtEchoAdd 1 Client ns stats (...) MPTcpExtAddAddr 1 MPTcpExtEchoAddTx 1 synack rx [FAIL] got 0 JOIN[s] synack rx expected 2 ack rx [FAIL] got 0 JOIN[s] ack rx expected 2 join Rx [FAIL] see above syn tx [FAIL] got 0 JOIN[s] syn tx expected 2 join Tx [FAIL] see above I had a suspicion about what the issue could be: the ADD_ADDR might have been received after the switch to the 'fully-established' state. The issue was not easy to reproduce. The packet capture shown that the ADD_ADDR can indeed be sent with a delay, and the client would not try to establish subflows to it as expected. A simple fix is not to mark the endpoints as 'used' in the C-flag case, when looking at creating subflows to the remote initial IP address and port. In this case, there is no need to try. Note: newly added fullmesh endpoints will still continue to be used as expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case. Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index e0f44dc232aa..2ae95476dba3 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -370,6 +370,10 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) } subflow: + /* No need to try establishing subflows to remote id0 if not allowed */ + if (mptcp_pm_add_addr_c_flag_case(msk)) + goto exit; + /* check if should create a new subflow */ while (msk->pm.local_addr_used < endp_subflow_max && msk->pm.extra_subflows < limit_extra_subflows) { @@ -401,6 +405,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) __mptcp_subflow_connect(sk, &local, &addrs[i]); spin_lock_bh(&msk->pm.lock); } + +exit: mptcp_pm_nl_check_work_pending(msk); }

4 days, 7 hours

3
2
0 0

[PATCH v2 0/9] dt-bindings: PCI: qcom: Add missing required power-domains and resets

by Krzysztof Kozlowski

Changes in v2: - Add also resets - Drop cc-stable tag in the last patch - Link to v1: https://patch.msgid.link/20251029-dt-bindings-pci-qcom-fixes-power-domains-… Recent binding changes forgot to make power-domains and resets required. I am not updating SC8180xp because it will be fixed other way in my next patchset. Best regards, Krzysztof --- Krzysztof Kozlowski (9): dt-bindings: PCI: qcom,pcie-sa8775p: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sc7280: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sc8280xp: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8150: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8250: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8350: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8450: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-sm8550: Add missing required power-domains and resets dt-bindings: PCI: qcom,pcie-x1e80100: Add missing required power-domains and resets Documentation/devicetree/bindings/pci/qcom,pcie-sa8775p.yaml | 3 +++ Documentation/devicetree/bindings/pci/qcom,pcie-sc7280.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sc8280xp.yaml | 3 +++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8150.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8250.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8350.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml | 5 +++++ Documentation/devicetree/bindings/pci/qcom,pcie-x1e80100.yaml | 5 +++++ 9 files changed, 41 insertions(+) --- base-commit: 326bbf6e2b1ce8d1e6166cce2ca414aa241c382f change-id: 20251029-dt-bindings-pci-qcom-fixes-power-domains-36a669b2e252 Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

4 days, 8 hours

4
10
0 0

[PATCH] can: rcar_canfd: Fix controller mode setting for RZ/G2L SoCs

by Biju

From: Biju Das <biju.das.jz(a)bp.renesas.com> The commit 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") applies to all SoCs except the RZ/G2L family of SoCs. As per RZ/G2L hardware manual "Figure 28.16 CAN Setting Procedure after the MCU is Reset" CAN mode needs to be set before channel reset. Add the mode_before_ch_rst variable to struct rcar_canfd_hw_info to handle this difference. The above commit also breaks CANFD functionality on RZ/G3E. Adapt this change to RZ/G3E, as well as it works ok by following the initialisation sequence of RZ/G2L. Fixes: 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") Cc: stable(a)vger.kernel.org Signed-off-by: Biju Das <biju.das.jz(a)bp.renesas.com> --- drivers/net/can/rcar/rcar_canfd.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c index 49ab65274b51..1724fa5dace6 100644 --- a/drivers/net/can/rcar/rcar_canfd.c +++ b/drivers/net/can/rcar/rcar_canfd.c @@ -444,6 +444,7 @@ struct rcar_canfd_hw_info { unsigned ch_interface_mode:1; /* Has channel interface mode */ unsigned shared_can_regs:1; /* Has shared classical can registers */ unsigned external_clk:1; /* Has external clock */ + unsigned mode_before_ch_rst:1; /* Has set mode before channel reset */ }; /* Channel priv data */ @@ -615,6 +616,7 @@ static const struct rcar_canfd_hw_info rcar_gen3_hw_info = { .ch_interface_mode = 0, .shared_can_regs = 0, .external_clk = 1, + .mode_before_ch_rst = 0, }; static const struct rcar_canfd_hw_info rcar_gen4_hw_info = { @@ -632,6 +634,7 @@ static const struct rcar_canfd_hw_info rcar_gen4_hw_info = { .ch_interface_mode = 1, .shared_can_regs = 1, .external_clk = 1, + .mode_before_ch_rst = 0, }; static const struct rcar_canfd_hw_info rzg2l_hw_info = { @@ -649,6 +652,7 @@ static const struct rcar_canfd_hw_info rzg2l_hw_info = { .ch_interface_mode = 0, .shared_can_regs = 0, .external_clk = 1, + .mode_before_ch_rst = 1, }; static const struct rcar_canfd_hw_info r9a09g047_hw_info = { @@ -666,6 +670,7 @@ static const struct rcar_canfd_hw_info r9a09g047_hw_info = { .ch_interface_mode = 1, .shared_can_regs = 1, .external_clk = 0, + .mode_before_ch_rst = 1, }; /* Helper functions */ @@ -806,6 +811,10 @@ static int rcar_canfd_reset_controller(struct rcar_canfd_global *gpriv) /* Reset Global error flags */ rcar_canfd_write(gpriv->base, RCANFD_GERFL, 0x0); + /* RZ/G2L SoC needs setting the mode before channel reset */ + if (gpriv->info->mode_before_ch_rst) + rcar_canfd_set_mode(gpriv); + /* Transition all Channels to reset mode */ for_each_set_bit(ch, &gpriv->channels_mask, gpriv->info->max_channels) { rcar_canfd_clear_bit(gpriv->base, @@ -826,7 +835,8 @@ static int rcar_canfd_reset_controller(struct rcar_canfd_global *gpriv) } /* Set the controller into appropriate mode */ - rcar_canfd_set_mode(gpriv); + if (!gpriv->info->mode_before_ch_rst) + rcar_canfd_set_mode(gpriv); return 0; } -- 2.43.0

4 days, 10 hours

4
6
0 0

[PATCH 6.1] softirq: Add trace points for tasklet entry/exit

by Sumanth Gavini

commit f4bf3ca2e5cba655824b6e0893a98dfb33ed24e5 upstream. Tasklets are supposed to finish their work quickly and should not block the current running process, but it is not guaranteed that they do so. Currently softirq_entry/exit can be used to analyse the total tasklets execution time, but that's not helpful to track individual tasklets execution time. That makes it hard to identify tasklet functions, which take more time than expected. Add tasklet_entry/exit trace point support to track individual tasklet execution. Trivial usage example: # echo 1 > /sys/kernel/debug/tracing/events/irq/tasklet_entry/enable # echo 1 > /sys/kernel/debug/tracing/events/irq/tasklet_exit/enable # cat /sys/kernel/debug/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 4/4 #P:4 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | <idle>-0 [003] ..s1. 314.011428: tasklet_entry: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func <idle>-0 [003] ..s1. 314.011432: tasklet_exit: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func <idle>-0 [003] ..s1. 314.017369: tasklet_entry: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func <idle>-0 [003] ..s1. 314.017371: tasklet_exit: tasklet=0xffffa01ef8db2740 function=tcp_tasklet_func Signed-off-by: Lingutla Chandrasekhar <clingutla(a)codeaurora.org> Signed-off-by: J. Avila <elavila(a)google.com> Signed-off-by: John Stultz <jstultz(a)google.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Link: https://lore.kernel.org/r/20230407230526.1685443-1-jstultz@google.com [elavila: Port to android-mainline] [jstultz: Rebased to upstream, cut unused trace points, added comments for the tracepoints, reworded commit] Signed-off-by: Sumanth Gavini <sumanth.gavini(a)yahoo.com> --- include/trace/events/irq.h | 47 ++++++++++++++++++++++++++++++++++++++ kernel/softirq.c | 9 ++++++-- 2 files changed, 54 insertions(+), 2 deletions(-) diff --git a/include/trace/events/irq.h b/include/trace/events/irq.h index eeceafaaea4c..a07b4607b663 100644 --- a/include/trace/events/irq.h +++ b/include/trace/events/irq.h @@ -160,6 +160,53 @@ DEFINE_EVENT(softirq, softirq_raise, TP_ARGS(vec_nr) ); +DECLARE_EVENT_CLASS(tasklet, + + TP_PROTO(struct tasklet_struct *t, void *func), + + TP_ARGS(t, func), + + TP_STRUCT__entry( + __field( void *, tasklet) + __field( void *, func) + ), + + TP_fast_assign( + __entry->tasklet = t; + __entry->func = func; + ), + + TP_printk("tasklet=%ps function=%ps", __entry->tasklet, __entry->func) +); + +/** + * tasklet_entry - called immediately before the tasklet is run + * @t: tasklet pointer + * @func: tasklet callback or function being run + * + * Used to find individual tasklet execution time + */ +DEFINE_EVENT(tasklet, tasklet_entry, + + TP_PROTO(struct tasklet_struct *t, void *func), + + TP_ARGS(t, func) +); + +/** + * tasklet_exit - called immediately after the tasklet is run + * @t: tasklet pointer + * @func: tasklet callback or function being run + * + * Used to find individual tasklet execution time + */ +DEFINE_EVENT(tasklet, tasklet_exit, + + TP_PROTO(struct tasklet_struct *t, void *func), + + TP_ARGS(t, func) +); + #endif /* _TRACE_IRQ_H */ /* This part must be outside protection */ diff --git a/kernel/softirq.c b/kernel/softirq.c index 9ab5ca399a99..fadc6bbda27b 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -822,10 +822,15 @@ static void tasklet_action_common(struct softirq_action *a, if (tasklet_trylock(t)) { if (!atomic_read(&t->count)) { if (tasklet_clear_sched(t)) { - if (t->use_callback) + if (t->use_callback) { + trace_tasklet_entry(t, t->callback); t->callback(t); - else + trace_tasklet_exit(t, t->callback); + } else { + trace_tasklet_entry(t, t->func); t->func(t->data); + trace_tasklet_exit(t, t->func); + } } tasklet_unlock(t); continue; -- 2.43.0

4 days, 20 hours

5
10
0 0

[PATCH] Bluetooth: btusb: Add one more ID 0x13d3:0x3612 for Realtek 8852CE

by Levi Zim via B4 Relay

From: Levi Zim <rsworktech(a)outlook.com> Devices with ID 13d3:3612 are found in ASUS TUF Gaming A16 (2025) and ASUS TX Gaming FA608FM. The corresponding device info from /sys/kernel/debug/usb/devices is T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=02 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Levi Zim <rsworktech(a)outlook.com> --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8085fabadde8ff01171783b59226589757bbbbbc..d1e62b3158166a33153a6dfaade03fd3fb7d8231 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -552,6 +552,8 @@ static const struct usb_device_id quirks_table[] = { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3592), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3612), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0489, 0xe122), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, --- base-commit: 302a1f674c00dd5581ab8e493ef44767c5101aab change-id: 20250927-ble-13d3-3612-53a2246e4862 Best regards, -- Levi Zim <rsworktech(a)outlook.com>

6 days, 8 hours

4
3
0 0

btrfs task hung in `lock_extent` syzbot report and CVE-2024-35784

by Andrey Kalachev

Hi. I've check c-repro [1] on 6.1.y branch and found that repro still produce the crash on 6.1.y. I notice that syzbot bisection result [2] is incorrect: indeed, the hung was fixed by upstream commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). Also, I saw CVE-2024-35784 [3][4] vulnerability, that have direct relation with that syzbot report. Therefore, syzbot reproducer provided additional way to check for CVE-2024-35784. I attempted to fix CVE-2024-35784 in stable 6.1.y (over v6.1.157), and found that the initial fix commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") introduced regressions [5][6]. IMHO here is the minimum patch series to eliminate CVE-2024-35784 from 6.1.y: b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") (Initial fix of the CVE-2024-35784) a1a4a9ca77f1 ("btrfs: fix race between ordered extent completion and fiemap") (Fixes: b0ad381fa769) 978b63f7464a ("btrfs: fix race when detecting delalloc ranges during fiemap") (Fixes: b0ad381fa769) 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") (Optimization: 978b63f7464a) 53e24158684b ("btrfs: set start on clone before calling copy_extent_buffer_full") (Fixes: 1cab1375ba6d) Required patches attached. Only two patches in the series have minor backport modifications due to v6.1.157 btrfs code differences. The remaining patches are identical to the upstream. Regards, AK Reported-by: syzbot+f8217aae382555004877(a)syzkaller.appspotmail.com ---- [1] https://syzkaller.appspot.com/text?tag=ReproC&x=12b4c88b280000 [2] https://syzkaller.appspot.com/bug?extid=f8217aae382555004877 [3] https://lore.kernel.org/all/2024051704-CVE-2024-35784-6dec@gregkh/ [4] https://cve.org/CVERecord/?id=CVE-2024-35784 [5] https://lore.kernel.org/linux-btrfs/cover.1709202499.git.fdmanana@suse.com/ [6] https://lore.kernel.org/all/20240304211551.880347593@linuxfoundation.org/

1 week

1
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2025