February 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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-6.6.y git checkout FETCH_HEAD git cherry-pick -x 5ae4dca718eacd0a56173a687a3736eb7e627c77 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025022438-automated-recycled-cc12@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5ae4dca718eacd0a56173a687a3736eb7e627c77 Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Tue, 21 Jan 2025 13:56:04 +0100 Subject: [PATCH] arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit UART controllers without flow control seem to behave unstable in case DMA is enabled. The issues were indicated in the message: https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0A… In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple of hours of UART communication, the CPU stall was occurring, leading to the system becoming unresponsive. After disabling the DMA, extensive UART communication tests for up to two weeks were performed, and no issues were further observed. The flow control pins for uart5 are not available on PX30-uQ7 Ringneck, as configured by pinctrl-0, so the DMA nodes were removed on SoM dtsi. Cc: stable(a)vger.kernel.org Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard") Reviewed-by: Quentin Schulz <quentin.schulz(a)cherry.de> Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250121125604.3115235-3-lukasz.czechowski@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi index 2c87005c89bd..e80412abec08 100644 --- a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi @@ -397,6 +397,8 @@ &u2phy_host { }; &uart5 { + /delete-property/ dmas; + /delete-property/ dma-names; pinctrl-0 = <&uart5_xfer>; };

8 months, 2 weeks

5
4
0 0

[PATCH v6.1-v5.4 1/1] pfifo_tail_enqueue: Drop new packet when sch->limit == 0

by Lee Jones

[ Upstream commit 647cef20e649c576dff271e018d5d15d998b629d ] Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. Fixes: 57dbb2d83d10 ("sched: add head drop fifo queue") Reported-by: Quang Le <quanglex97(a)gmail.com> Signed-off-by: Quang Le <quanglex97(a)gmail.com> Signed-off-by: Cong Wang <cong.wang(a)bytedance.com> Link: https://patch.msgid.link/20250204005841.223511-2-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Lee: Backported to linux-6.6.y - fixed a minor surrounding diff conflict] (cherry picked from commit e40cb34b7f247fe2e366fd192700d1b4f38196ca) Signed-off-by: Lee Jones <lee(a)kernel.org> --- - Applies cleanly to v6.1, v5.15, v5.10 and v5.4 net/sched/sch_fifo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/sched/sch_fifo.c b/net/sched/sch_fifo.c index e1040421b797..af5f2ab69b8d 100644 --- a/net/sched/sch_fifo.c +++ b/net/sched/sch_fifo.c @@ -39,6 +39,9 @@ static int pfifo_tail_enqueue(struct sk_buff *skb, struct Qdisc *sch, { unsigned int prev_backlog; + if (unlikely(READ_ONCE(sch->limit) == 0)) + return qdisc_drop(skb, sch, to_free); + if (likely(sch->q.qlen < sch->limit)) return qdisc_enqueue_tail(skb, sch); -- 2.48.1.658.g4767266eb4-goog

8 months, 2 weeks

1
0
0 0

[BUG] r8188eu: Potential deadlocks in rtw_wx_set_wap/essid functions

by Gui-Dong Han

Hello maintainers, I would like to report a potential lock ordering issue in the r8188eu driver. This may lead to deadlocks under certain conditions. The functions rtw_wx_set_wap() and rtw_wx_set_essid() acquire locks in an order that contradicts the established locking hierarchy observed in other parts of the driver: 1. They first take &pmlmepriv->scanned_queue.lock 2. Then call rtw_set_802_11_infrastructure_mode() which takes &pmlmepriv->lock This is inverted compared to the common pattern seen in functions like rtw_joinbss_event_prehandle(), rtw_createbss_cmd_callback(), and others, which typically: 1. Take &pmlmepriv->lock first 2. Then take &pmlmepriv->scanned_queue.lock This lock inversion creates a potential deadlock scenario when these code paths execute concurrently. Moreover, the call chain: rtw_wx_set_* -> rtw_set_802_11_infrastructure_mode() -> rtw_free_assoc_resources() could lead to recursive acquisition of &pmlmepriv->scanned_queue.lock, potentially causing self-deadlock even without concurrency. This issue exists in longterm kernels containing the r8188eu driver: 5.4.y (until 5.4.290) 5.10.y (until 5.10.234) 5.15.y (until 5.15.178) 6.1.y (until 6.1.129) The r8188eu driver has been removed from upstream, but older maintained versions (5.4.x–6.1.x) still include this driver and are affected. This issue was identified through static analysis. While I've verified the locking patterns through code review, I'm not sufficiently familiar with the driver's internals to propose a safe fix. Thank you for your attention to this matter. Best regards, Gui-Dong Han

8 months, 2 weeks

3
2
0 0

[PATCH 1/3] perf/x86: Fix low freq setting issue

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> Perf doesn't work with a low freq. perf record -e cpu_core/instructions/ppp -F 120 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_core/instructions/ppp). "dmesg | grep -i perf" may provide additional information. The limit_period() check avoids a low sampling period on a counter. It doesn't intend to limit the frequency. The check in the x86_pmu_hw_config() should be limited to non-freq mode. The attr.sample_period and attr.sample_freq are union. The attr.sample_period should not be used to indicate the freq mode. Fixes: c46e665f0377 ("perf/x86: Add INST_RETIRED.ALL workarounds") Closes: https://lore.kernel.org/lkml/20250115154949.3147-1-ravi.bangoria@amd.com/ Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Ravi Bangoria <ravi.bangoria(a)amd.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 7b6430e5a77b..20ad5cca6ad2 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -630,7 +630,7 @@ int x86_pmu_hw_config(struct perf_event *event) if (event->attr.type == event->pmu->type) event->hw.config |= x86_pmu_get_event_config(event); - if (event->attr.sample_period && x86_pmu.limit_period) { + if (!event->attr.freq && x86_pmu.limit_period) { s64 left = event->attr.sample_period; x86_pmu.limit_period(event, &left); if (left > event->attr.sample_period) -- 2.38.1

8 months, 2 weeks

3
5
0 0

[PATCH 6.1.y 0/3] vsock: fix use-after free and null-ptr-deref

by Luigi Leonardi

Hi all, This series backports three upstream commits: - 135ffc7 "bpf, vsock: Invoke proto::close on close()" - fcdd224 "vsock: Keep the binding until socket destruction" - 78dafe1 "vsock: Orphan socket after transport release" Although this version of the kernel does not support sockmap, I think backporting this patch can be useful to reduce conflicts in future backports [1]. It does not harm the system. The comment it introduces in the code can be misleading. I added some words in the commit to explain the situation. The other two commits are untouched, fixing a use-after free[2] and a null-ptr-deref[3] respectively. [1]https://lore.kernel.org/stable/f7lr3ftzo66sl6phlcygh4xx4spga4b6je37fhawjr… [2]https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-0-1cf… [3]https://lore.kernel.org/all/20250210-vsock-linger-nullderef-v3-0-ef6244d0… Cheers, Luigi To: Stefano Garzarella <sgarzare(a)redhat.com> To: Michal Luczaj <mhal(a)rbox.co> To: stable(a)vger.kernel.org Signed-off-by: Luigi Leonardi <leonardi(a)redhat.com> --- Michal Luczaj (3): bpf, vsock: Invoke proto::close on close() vsock: Keep the binding until socket destruction vsock: Orphan socket after transport release net/vmw_vsock/af_vsock.c | 77 +++++++++++++++++++++++++++++++----------------- 1 file changed, 50 insertions(+), 27 deletions(-) --- base-commit: 0cbb5f65e52f3e66410a7fe0edf75e1b2bf41e80 change-id: 20250220-backport_fix-9a9a58f64f14 Best regards, -- Luigi Leonardi <leonardi(a)redhat.com>

8 months, 2 weeks

1
3
0 0

[PATCH 5.15.y 0/3] vsock: fix use-after free and null-ptr-deref

by Luigi Leonardi

Hi all, This series backports three upstream commits: - 135ffc7 "bpf, vsock: Invoke proto::close on close()" - fcdd224 "vsock: Keep the binding until socket destruction" - 78dafe1 "vsock: Orphan socket after transport release" Although this version of the kernel does not support sockmap, I think backporting this patch can be useful to reduce conflicts in future backports [1]. It does not harm the system. The comment it introduces in the code can be misleading. I added some words in the commit to explain the situation. The other two commits are untouched, fixing a use-after free[2] and a null-ptr-deref[3] respectively. [1]https://lore.kernel.org/stable/f7lr3ftzo66sl6phlcygh4xx4spga4b6je37fhawjr… [2]https://lore.kernel.org/all/20250128-vsock-transport-vs-autobind-v3-0-1cf… [3]https://lore.kernel.org/all/20250210-vsock-linger-nullderef-v3-0-ef6244d0… Cheers, Luigi To: Stefano Garzarella <sgarzare(a)redhat.com> To: Michal Luczaj <mhal(a)rbox.co> To: stable(a)vger.kernel.org Signed-off-by: Luigi Leonardi <leonardi(a)redhat.com> --- Michal Luczaj (3): bpf, vsock: Invoke proto::close on close() vsock: Keep the binding until socket destruction vsock: Orphan socket after transport release net/vmw_vsock/af_vsock.c | 77 +++++++++++++++++++++++++++++++----------------- 1 file changed, 50 insertions(+), 27 deletions(-) --- base-commit: c16c81c81336c0912eb3542194f16215c0a40037 change-id: 20250220-backport_fix_5_15-27efd9233dc2 Best regards, -- Luigi Leonardi <leonardi(a)redhat.com>

8 months, 2 weeks

1
3
0 0

[PATCH] arm64: dts: qcom: sdm850-lenovo-yoga-c630: make SMMU non-DMA-coherent

by Dmitry Baryshkov

The commit 6b31a9744b87 ("arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu") enabled dma-coherent property for the IOMMU device. This works for some devices, like Qualcomm RB3 platform, but at the same time it breaks booting on Lenovo Yoga C630 (most likely because of some TZ differences). Disable DMA coherency for IOMMU on Lenove Yoga C630. Fixes: 6b31a9744b87 ("arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu") Cc: stable(a)vger.kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts index f18050848cd8892666015c8182971ff0567747b7..67a60ec33e8cf701a672696e7c7bd85120950441 100644 --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts @@ -342,6 +342,10 @@ vreg_lvs2a_1p8: lvs2 { }; }; +&apps_smmu { + /delete-property/ dma-coherent; +}; + &cdsp_pas { firmware-name = "qcom/sdm850/LENOVO/81JL/qccdsp850.mbn"; status = "okay"; --- base-commit: ed58d103e6da15a442ff87567898768dc3a66987 change-id: 20250215-yoga-dma-coherent-ea255630fd7d Best regards, -- Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org>

8 months, 2 weeks

2
1
0 0

[PATCH 0/8] gpiolib: sanitize return values of callbacks

by Bartosz Golaszewski

We've had instances of drivers returning invalid values from gpio_chip calbacks. In several cases these return values would be propagated to user-space and confuse programs that only expect 0 or negative errnos from ioctl()s. Let's sanitize the return values of callbacks and make sure we don't allow anyone see invalid ones. The first patch checks the return values of get_direction() in kernel where needed and is a backportable fix. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> --- Bartosz Golaszewski (8): gpiolib: check the return value of gpio_chip::get_direction() gpiolib: sanitize the return value of gpio_chip::request() gpiolib: sanitize the return value of gpio_chip::set_config() gpiolib: sanitize the return value of gpio_chip::get() gpiolib: sanitize the return value of gpio_chip::get_multiple() gpiolib: sanitize the return value of gpio_chip::direction_output() gpiolib: sanitize the return value of gpio_chip::direction_input() gpiolib: sanitize the return value of gpio_chip::get_direction() drivers/gpio/gpiolib.c | 144 +++++++++++++++++++++++++++++++++++--------- include/linux/gpio/driver.h | 6 +- 2 files changed, 120 insertions(+), 30 deletions(-) --- base-commit: a13f6e0f405ed0d3bcfd37c692c7d7fa3c052154 change-id: 20241212-gpio-sanitize-retvals-f5f4e0d6f57d Best regards, -- Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org>

8 months, 2 weeks

5
10
0 0

[PATCH v2 0/9] of: fix bugs about refcount

by Zijun Hu

This patch series is to fix of bugs about refcount. Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Changes in v2: - Add 2 unittest patches + 1 refcount bug fix + 1 refcount comments patch - Correct titles and commit messages - Link to v1: https://lore.kernel.org/r/20241209-of_irq_fix-v1-0-782f1419c8a1@quicinc.com --- Zijun Hu (9): of: unittest: Add a case to test if API of_irq_parse_one() leaks refcount of/irq: Fix device node refcount leakage in API of_irq_parse_one() of: unittest: Add a case to test if API of_irq_parse_raw() leaks refcount of/irq: Fix device node refcount leakage in API of_irq_parse_raw() of/irq: Fix device node refcount leakages in of_irq_count() of/irq: Fix device node refcount leakage in API irq_of_parse_and_map() of/irq: Fix device node refcount leakages in of_irq_init() of/irq: Add comments about refcount for API of_irq_find_parent() of: resolver: Fix device node refcount leakage in of_resolve_phandles() drivers/of/irq.c | 34 ++++++++++--- drivers/of/resolver.c | 2 + drivers/of/unittest-data/tests-interrupts.dtsi | 13 +++++ drivers/of/unittest.c | 67 ++++++++++++++++++++++++++ 4 files changed, 110 insertions(+), 6 deletions(-) --- base-commit: 40fc0083a9dbcf2e81b1506274cb541f84d022ed change-id: 20241208-of_irq_fix-659514bc9aa3 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

8 months, 2 weeks

2
8
0 0

Re: [PATCH 6.13 000/137] 6.13.5-rc2 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

8 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025