- Linux-stable-mirror - lists.linaro.org

[PATCH] LoongArch: BPF: Disable bpf trampoline kernel module function trace

by Vincent Li

The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * Kernel lockups when a BPF program is attached to a module function [0]. * The `bpf_selftests/module_attach` test fails consistently. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [1]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [0]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C… [1]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcF… Cc: stable(a)vger.kernel.org Fixes: f9b6b41f0cf3 (“LoongArch: BPF: Add basic bpf trampoline support”) Closes: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C… Acked-by: Hengqi Chen <hengqi.chen(a)gmail.com> Signed-off-by: Vincent Li <vincent.mc.li(a)gmail.com> --- arch/loongarch/net/bpf_jit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c index cbe53d0b7fb0..49c1d4b95404 100644 --- a/arch/loongarch/net/bpf_jit.c +++ b/arch/loongarch/net/bpf_jit.c @@ -1624,6 +1624,9 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i /* Direct jump skips 5 NOP instructions */ else if (is_bpf_text_address((unsigned long)orig_call)) orig_call += LOONGARCH_BPF_FENTRY_NBYTES; + /* Module tracing not supported - causes kernel lockups */ + else if (is_module_text_address((unsigned long)orig_call)) + return -ENOTSUPP; if (flags & BPF_TRAMP_F_CALL_ORIG) { move_addr(ctx, LOONGARCH_GPR_A0, (const u64)im); -- 2.38.1

2 days, 16 hours

1
1
0 0

[PATCH] LoongArch: BPF: Disable bpf trampoline kernel module function trace

by Vincent Li

The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * Kernel lockups when a BPF program is attached to a module function [0]. * The `bpf_selftests/module_attach` test fails consistently. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [1]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [0]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C… [1]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcF… Cc: stable(a)vger.kernel.org Fixes: f9b6b41f0cf3 (“LoongArch: BPF: Add basic bpf trampoline support”) Closes: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C… Acked-by: Hengqi Chen <hengqi.chen(a)gmail.com> Signed-off-by: Vincent Li <vincent.mc.li(a)gmail.com> --- arch/loongarch/net/bpf_jit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c index cbe53d0b7fb0..49c1d4b95404 100644 --- a/arch/loongarch/net/bpf_jit.c +++ b/arch/loongarch/net/bpf_jit.c @@ -1624,6 +1624,9 @@ static int __arch_prepare_bpf_trampoline(struct jit_ctx *ctx, struct bpf_tramp_i /* Direct jump skips 5 NOP instructions */ else if (is_bpf_text_address((unsigned long)orig_call)) orig_call += LOONGARCH_BPF_FENTRY_NBYTES; + /* Module tracing not supported - causes kernel lockups */ + else if (is_module_text_address((unsigned long)orig_call)) + return -ENOTSUPP; if (flags & BPF_TRAMP_F_CALL_ORIG) { move_addr(ctx, LOONGARCH_GPR_A0, (const u64)im); -- 2.38.1

2 days, 16 hours

1
0
0 0

[PATCH v4 phy 00/16] Lynx 28G improvements part 1

by Vladimir Oltean

This is the first part in upstreaming a set of around 100 patches that were developed in NXP's vendor Linux Factory kernel over the course of several years. This part is mainly concerned with correcting some historical mistakes which make extending the driver more difficult: - The 3 instances of this SerDes block, as seen on NXP LX2160A, need to be differentiated somehow, because otherwise, the driver cannot reject a configuration which is unsupported by the hardware. The proposal is to do that based on compatible string. - Lanes cannot have electrical parameters described in the device tree, because they are not described in the device tree. - The register naming scheme forces us to modify a single register field per lynx_28g_lane_rmw() call - leads to inefficient code - lynx_28g_lane_set_sgmii(), lynx_28g_lane_set_10gbaser() are unfit for their required roles when the current SerDes protocol is 25GBase-R. They are replaced with a better structured approach. - USXGMII and 10GBase-R have different protocol converters, and should be treated separately by the SerDes driver. The device tree binding + driver changes are all non-breaking. I also have device tree conversions for LX2160A and LX2162A which are also non-breaking due to their partial nature. If I were to replace patterns such as: phys = <&serdes_2 0>; with: phys = <&serdes_2_lane_a>; then the corresponding device tree conversions would also be breaking. I don't _need_ to do that to make progress, but eventually I would like to be able to. In order to be able to make that kind of change in a non-breaking manner in a reasonable number of years, I would like patches 1-3 to be backported to stable kernels. Compared to v3 here: https://lore.kernel.org/linux-phy/20250926180505.760089-1-vladimir.oltean@n… there are some new patches, but it overall shrank in size because I deferred new features to "part 2". Essentially, v4 is like v3, except with a better plan to handle device tree transitions without breakage, and with the following patches temporarily dropped: [PATCH v3 phy 14/17] phy: lynx-28g: add support for 25GBASER [PATCH v3 phy 15/17] phy: lynx-28g: use timeouts when waiting for lane halt and reset [PATCH v3 phy 16/17] phy: lynx-28g: truly power the lanes up or down [PATCH v3 phy 17/17] phy: lynx-28g: implement phy_exit() operation Compared to v2 here: https://lore.kernel.org/lkml/d0c8bbf8-a0c5-469f-a148-de2235948c0f@solid-run… v3 grew in size due to Josua's request to avoid unbounded loops waiting for lane resets/halts/stops to complete. Compared to v1 here: https://lore.kernel.org/lkml/20250904154402.300032-1-vladimir.oltean@nxp.co… v2 grew in size due to Josua's request for a device tree binding where individual lanes have their own OF nodes. This seems to be the right moment to make that change. Detailed change log in individual patches. Thanks to Josua, Rob, Conor, Krzysztof, Ioana who provided feedback on the previous version, and I hope it has all been addressed. Cc: Rob Herring <robh(a)kernel.org> Cc: Krzysztof Kozlowski <krzk+dt(a)kernel.org> Cc: Conor Dooley <conor+dt(a)kernel.org> Cc: devicetree(a)vger.kernel.org Cc: stable(a)vger.kernel.org Ioana Ciornei (1): phy: lynx-28g: configure more equalization params for 1GbE and 10GbE Vladimir Oltean (15): dt-bindings: phy: lynx-28g: permit lane OF PHY providers phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane() phy: lynx-28g: support individual lanes as OF PHY providers phy: lynx-28g: remove LYNX_28G_ prefix from register names phy: lynx-28g: don't concatenate lynx_28g_lane_rmw() argument "reg" with "val" and "mask" phy: lynx-28g: use FIELD_GET() and FIELD_PREP() phy: lynx-28g: convert iowrite32() calls with magic values to macros phy: lynx-28g: restructure protocol configuration register accesses phy: lynx-28g: make lynx_28g_set_lane_mode() more systematic phy: lynx-28g: refactor lane->interface to lane->mode phy: lynx-28g: distinguish between 10GBASE-R and USXGMII phy: lynx-28g: use "dev" argument more in lynx_28g_probe() phy: lynx-28g: improve lynx_28g_probe() sequence dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation phy: lynx-28g: probe on per-SoC and per-instance compatible strings .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 153 +- drivers/phy/freescale/phy-fsl-lynx-28g.c | 1271 +++++++++++++---- 2 files changed, 1134 insertions(+), 290 deletions(-) -- 2.34.1

2 days, 17 hours

3
8
0 0

Re: Patch "mptcp: drop bogus optimization in __mptcp_check_push()" has been added to the 5.15-stable tree

by Matthieu Baerts

Hi Greg, Sasha, On 03/11/2025 02:38, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > mptcp: drop bogus optimization in __mptcp_check_push() > > to the 5.15-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > mptcp-drop-bogus-optimization-in-__mptcp_check_push.patch > and it can be found in the queue-5.15 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Can you please drop this patch from v5.15? It looks like it is causing some issues with MP_PRIO tests. I think that's because back then, the path is selected differently, with the use of 'msk->last_snd' which will bypass some decisions to where to send the next data. I will try to check if another version of this patch is needed for v5.15. Cheers, Matt (I kept the patch below just in case some people from the MPTCP ML want to react.) > From stable+bounces-192087-greg=kroah.com(a)vger.kernel.org Mon Nov 3 05:15:58 2025 > From: Sasha Levin <sashal(a)kernel.org> > Date: Sun, 2 Nov 2025 15:15:50 -0500 > Subject: mptcp: drop bogus optimization in __mptcp_check_push() > To: stable(a)vger.kernel.org > Cc: Paolo Abeni <pabeni(a)redhat.com>, Geliang Tang <geliang(a)kernel.org>, Mat Martineau <martineau(a)kernel.org>, "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org>, Jakub Kicinski <kuba(a)kernel.org>, Sasha Levin <sashal(a)kernel.org> > Message-ID: <20251102201550.3588174-1-sashal(a)kernel.org> > > From: Paolo Abeni <pabeni(a)redhat.com> > > [ Upstream commit 27b0e701d3872ba59c5b579a9e8a02ea49ad3d3b ] > > Accessing the transmit queue without owning the msk socket lock is > inherently racy, hence __mptcp_check_push() could actually quit early > even when there is pending data. > > That in turn could cause unexpected tx lock and timeout. > > Dropping the early check avoids the race, implicitly relaying on later > tests under the relevant lock. With such change, all the other > mptcp_send_head() call sites are now under the msk socket lock and we > can additionally drop the now unneeded annotation on the transmit head > pointer accesses. > > Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") > Cc: stable(a)vger.kernel.org > Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> > Reviewed-by: Geliang Tang <geliang(a)kernel.org> > Tested-by: Geliang Tang <geliang(a)kernel.org> > Reviewed-by: Mat Martineau <martineau(a)kernel.org> > Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> > Link: https://patch.msgid.link/20251028-net-mptcp-send-timeout-v1-1-38ffff5a9ec8@… > Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> > [ split upstream __subflow_push_pending modification across __mptcp_push_pending and __mptcp_subflow_push_pending ] > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > net/mptcp/protocol.c | 13 +++++-------- > net/mptcp/protocol.h | 2 +- > 2 files changed, 6 insertions(+), 9 deletions(-) > > --- a/net/mptcp/protocol.c > +++ b/net/mptcp/protocol.c > @@ -1137,7 +1137,7 @@ static void __mptcp_clean_una(struct soc > if (WARN_ON_ONCE(!msk->recovery)) > break; > > - WRITE_ONCE(msk->first_pending, mptcp_send_next(sk)); > + msk->first_pending = mptcp_send_next(sk); > } > > dfrag_clear(sk, dfrag); > @@ -1674,7 +1674,7 @@ void __mptcp_push_pending(struct sock *s > > mptcp_update_post_push(msk, dfrag, ret); > } > - WRITE_ONCE(msk->first_pending, mptcp_send_next(sk)); > + msk->first_pending = mptcp_send_next(sk); > } > > /* at this point we held the socket lock for the last subflow we used */ > @@ -1732,7 +1732,7 @@ static void __mptcp_subflow_push_pending > > mptcp_update_post_push(msk, dfrag, ret); > } > - WRITE_ONCE(msk->first_pending, mptcp_send_next(sk)); > + msk->first_pending = mptcp_send_next(sk); > } > > out: > @@ -1850,7 +1850,7 @@ static int mptcp_sendmsg(struct sock *sk > get_page(dfrag->page); > list_add_tail(&dfrag->list, &msk->rtx_queue); > if (!msk->first_pending) > - WRITE_ONCE(msk->first_pending, dfrag); > + msk->first_pending = dfrag; > } > pr_debug("msk=%p dfrag at seq=%llu len=%u sent=%u new=%d\n", msk, > dfrag->data_seq, dfrag->data_len, dfrag->already_sent, > @@ -2645,7 +2645,7 @@ static void __mptcp_clear_xmit(struct so > struct mptcp_sock *msk = mptcp_sk(sk); > struct mptcp_data_frag *dtmp, *dfrag; > > - WRITE_ONCE(msk->first_pending, NULL); > + msk->first_pending = NULL; > list_for_each_entry_safe(dfrag, dtmp, &msk->rtx_queue, list) > dfrag_clear(sk, dfrag); > } > @@ -3114,9 +3114,6 @@ void __mptcp_data_acked(struct sock *sk) > > void __mptcp_check_push(struct sock *sk, struct sock *ssk) > { > - if (!mptcp_send_head(sk)) > - return; > - > if (!sock_owned_by_user(sk)) { > struct sock *xmit_ssk = mptcp_subflow_get_send(mptcp_sk(sk)); > > --- a/net/mptcp/protocol.h > +++ b/net/mptcp/protocol.h > @@ -325,7 +325,7 @@ static inline struct mptcp_data_frag *mp > { > const struct mptcp_sock *msk = mptcp_sk(sk); > > - return READ_ONCE(msk->first_pending); > + return msk->first_pending; > } > > static inline struct mptcp_data_frag *mptcp_send_next(struct sock *sk) Cheers, Matt -- Sponsored by the NGI0 Core fund.

2 days, 18 hours

2
1
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); }

2 days, 18 hours

2
1
0 0

[PATCH] iommu/amd: Fix pci_segment memleak in alloc_pci_segment()

by Jinhui Guo

Fix a memory leak of struct amd_iommu_pci_segment in alloc_pci_segment() when system memory (or contiguous memory) is insufficient. Fixes: 04230c119930 ("iommu/amd: Introduce per PCI segment device table") Fixes: eda797a27795 ("iommu/amd: Introduce per PCI segment rlookup table") Fixes: 99fc4ac3d297 ("iommu/amd: Introduce per PCI segment alias_table") Cc: stable(a)vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- drivers/iommu/amd/init.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index ba9e582a8bbe..77afd5884984 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -1608,13 +1608,22 @@ static struct amd_iommu_pci_seg *__init alloc_pci_segment(u16 id, list_add_tail(&pci_seg->list, &amd_iommu_pci_seg_list); if (alloc_dev_table(pci_seg)) - return NULL; + goto err_free_pci_seg; if (alloc_alias_table(pci_seg)) - return NULL; + goto err_free_dev_table; if (alloc_rlookup_table(pci_seg)) - return NULL; + goto err_free_alias_table; return pci_seg; + +err_free_alias_table: + free_alias_table(pci_seg); +err_free_dev_table: + free_dev_table(pci_seg); +err_free_pci_seg: + list_del(&pci_seg->list); + kfree(pci_seg); + return NULL; } static struct amd_iommu_pci_seg *__init get_pci_segment(u16 id, -- 2.20.1

2 days, 18 hours

2
2
0 0

[PATCH] usb: phy: Initialize struct usb_phy list_head

by Diogo Ivo

When executing usb_add_phy() and usb_add_phy_dev() it is possible that usb_add_extcon() fails (for example with -EPROBE_DEFER), in which case the usb_phy does not get added to phy_list via list_add_tail(&x->head, phy_list). Then, when the driver that tried to add the phy receives the error propagated from usb_add_extcon() and calls into usb_remove_phy() to undo the partial registration there will be an unconditional call to list_del(&x->head) which is notinitialized and leads to a NULL pointer dereference. Fix this by initializing x->head before usb_add_extcon() has a chance to fail. Fixes: 7d21114dc6a2d53 ("usb: phy: Introduce one extcon device into usb phy") Cc: stable(a)vger.kernel.org Signed-off-by: Diogo Ivo <diogo.ivo(a)tecnico.ulisboa.pt> --- drivers/usb/phy/phy.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c index e1435bc59662..5a9b9353f343 100644 --- a/drivers/usb/phy/phy.c +++ b/drivers/usb/phy/phy.c @@ -646,6 +646,8 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type) return -EINVAL; } + INIT_LIST_HEAD(&x->head); + usb_charger_init(x); ret = usb_add_extcon(x); if (ret) @@ -696,6 +698,8 @@ int usb_add_phy_dev(struct usb_phy *x) return -EINVAL; } + INIT_LIST_HEAD(&x->head); + usb_charger_init(x); ret = usb_add_extcon(x); if (ret) --- base-commit: 35d084745b3ea4af571ed421844f2bb1a99ad6e2 change-id: 20251113-diogo-smaug_typec-56b2059b892b Best regards, -- Diogo Ivo <diogo.ivo(a)tecnico.ulisboa.pt>

2 days, 18 hours

1
0
0 0

[PATCH] tty: serial: sh-sci: fix RSCI FIFO overrun handling

by Cosmin Tanislav

The receive error handling code is shared between RSCI and all other SCIF port types, but the RSCI overrun_reg is specified as a memory offset, while for other SCIF types it is an enum value used to index into the sci_port_params->regs array, as mentioned above the sci_serial_in() function. For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call inside the sci_handle_fifo_overrun() function to index outside the bounds of the regs array, which currently has a size of 20, as specified by SCI_NR_REGS. Because of this, we end up accessing memory outside of RSCI's rsci_port_params structure, which, when interpreted as a plat_sci_reg, happens to have a non-zero size, causing the following WARN when sci_serial_in() is called, as the accidental size does not match the supported register sizes. The existence of the overrun_reg needs to be checked because SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not present in the regs array. Avoid calling sci_getreg() for port types which don't use standard register handling. Use the ops->read_reg() and ops->write_reg() functions to properly read and write registers for RSCI, and change the type of the status variable to accommodate the 32-bit CSR register. sci_getreg() and sci_serial_in() are also called with overrun_reg in the sci_mpxed_interrupt() interrupt handler, but that code path is not used for RSCI, as it does not have a muxed interrupt. ------------[ cut here ]------------ Invalid register access WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sci_serial_in+0x38/0xac lr : sci_serial_in+0x38/0xac sp : ffff800080003e80 x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80 x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000 x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48 x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48 x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80 Call trace: sci_serial_in+0x38/0xac (P) sci_handle_fifo_overrun.isra.0+0x70/0x134 sci_er_interrupt+0x50/0x39c __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x44/0xb0 handle_fasteoi_irq+0xf4/0x1a0 handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x140 call_on_irq_stack+0x30/0x48 do_interrupt_handler+0x80/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 default_idle_call+0x28/0x58 (P) do_idle+0x1f8/0x250 cpu_startup_entry+0x34/0x3c rest_init+0xd8/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ---[ end trace 0000000000000000 ]--- Cc: stable(a)vger.kernel.org Fixes: 0666e3fe95ab ("serial: sh-sci: Add support for RZ/T2H SCI") Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa(a)renesas.com> --- drivers/tty/serial/sh-sci.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 538b2f991609..62bb62b82cbe 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -1014,16 +1014,18 @@ static int sci_handle_fifo_overrun(struct uart_port *port) struct sci_port *s = to_sci_port(port); const struct plat_sci_reg *reg; int copied = 0; - u16 status; + u32 status; - reg = sci_getreg(port, s->params->overrun_reg); - if (!reg->size) - return 0; + if (s->type != SCI_PORT_RSCI) { + reg = sci_getreg(port, s->params->overrun_reg); + if (!reg->size) + return 0; + } - status = sci_serial_in(port, s->params->overrun_reg); + status = s->ops->read_reg(port, s->params->overrun_reg); if (status & s->params->overrun_mask) { status &= ~s->params->overrun_mask; - sci_serial_out(port, s->params->overrun_reg, status); + s->ops->write_reg(port, s->params->overrun_reg, status); port->icount.overrun++; -- 2.51.0

2 days, 19 hours

3
4
0 0

[PATCH] libfs: Fix NULL pointer access in simple_recursive_removal

by rom.wang

From: Yufeng Wang <wangyufeng(a)kylinos.cn> There is an issue in the kernel: if inode is NULL pointer. the function "inode_lock_nested" (or function "inode_lock" before) a crash will happen at code "&inode->i_rwsem". [292618.520532] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 [...] [292618.560398] RIP: 0010:down_write+0x12/0x30 [292618.565580] Code: 83 f8 01 74 08 48 c7 47 20 01 00 00 00 f3 c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 ba 01 00 00 00 ff ff ff ff 48 89 f8 <f0> 48 0f c1 10 85 d2 74 05 e8 00 43 ff ff 65 48 8b 04 25 80 5c 01 [292618.587219] RSP: 0018:ffffb898dc86fc20 EFLAGS: 00010246 [292618.593666] RAX: 00000000000000a0 RBX: ffff94c84f363950 RCX: ffffff8000000000 [292618.602255] RDX: ffffffff00000001 RSI: 0000000000000063 RDI: 00000000000000a0 [292618.610844] RBP: ffffb898dc86fc78 R08: 0000000000000000 R09: 0000000000000000 [292618.619434] R10: ffffb898dc86fca8 R11: 0000000000000000 R12: 0000000000000000 [292618.628022] R13: ffff94c84f362a20 R14: ffff954d3f2fb4a0 R15: ffff954c3afa5010 [292618.636612] FS: 0000555555989cc0(0000) GS:ffff956dbf900000(0000) knlGS:0000000000000000 [292618.646271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [292618.653300] CR2: 00000000000000a0 CR3: 000000fc7f25a000 CR4: 00000000003406e0 [292618.661888] Call Trace: [292618.665225] simple_recursive_removal+0x4f/0x230 [292618.670994] ? debug_fill_super+0xe0/0xe0 [292618.676079] debugfs_remove+0x40/0x60 [292618.680799] kvm_vcpu_release+0x19/0x30 [kvm] Fixes: a3d1e7eb5abe ("simple_recursive_removal(): kernel-side rm -rf for ramfs-style filesystems") Cc: stable(a)vger.kernel.org Signed-off-by: Yufeng Wang <wangyufeng(a)kylinos.cn> --- fs/libfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/libfs.c b/fs/libfs.c index 1661dcb7d983..9090cd1f97c4 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -611,6 +611,8 @@ static void __simple_recursive_removal(struct dentry *dentry, struct dentry *victim = NULL, *child; struct inode *inode = this->d_inode; + if (!inode) + return; inode_lock_nested(inode, I_MUTEX_CHILD); if (d_is_dir(this)) inode->i_flags |= S_DEAD; -- 2.34.1

2 days, 20 hours

2
1
0 0

[PATCH v5] block: Remove queue freezing from several sysfs store callbacks

by Bart Van Assche

Freezing the request queue from inside sysfs store callbacks may cause a deadlock in combination with the dm-multipath driver and the queue_if_no_path option. Additionally, freezing the request queue slows down system boot on systems where sysfs attributes are set synchronously. Fix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue() calls from the store callbacks that do not strictly need these callbacks. This patch may cause a small delay in applying the new settings. This patch affects the following sysfs attributes: * io_poll_delay * io_timeout * nomerges * read_ahead_kb * rq_affinity Here is an example of a deadlock triggered by running test srp/002: task:multipathd Call Trace: <TASK> __schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 schedule_preempt_disabled+0x1c/0x30 __mutex_lock+0xb89/0x1650 mutex_lock_nested+0x1f/0x30 dm_table_set_restrictions+0x823/0xdf0 __bind+0x166/0x590 dm_swap_table+0x2a7/0x490 do_resume+0x1b1/0x610 dev_suspend+0x55/0x1a0 ctl_ioctl+0x3a5/0x7e0 dm_ctl_ioctl+0x12/0x20 __x64_sys_ioctl+0x127/0x1a0 x64_sys_call+0xe2b/0x17d0 do_syscall_64+0x96/0x3a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> task:(udev-worker) Call Trace: <TASK> __schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 blk_mq_freeze_queue_wait+0xf2/0x140 blk_mq_freeze_queue_nomemsave+0x23/0x30 queue_ra_store+0x14e/0x290 queue_attr_store+0x23e/0x2c0 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3b2/0x630 vfs_write+0x4fd/0x1390 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x276/0x17d0 do_syscall_64+0x96/0x3a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: Nilay Shroff <nilay(a)linux.ibm.com> Cc: Martin Wilck <mwilck(a)suse.com> Cc: Benjamin Marzinski <bmarzins(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: af2814149883 ("block: freeze the queue in queue_attr_store") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> --- Changes compared to v4: - Use WRITE_ONCE() to update bdi->ra_pages. - Move a data_race() annotation from queue_io_timeout_store() into blk_queue_rq_timeout(). Changes compared to v3: - Added two data_race() annotations. Changes compared to v2: - Dropped the controversial patch "block: Restrict the duration of sysfs attribute changes". Changes compared to v1: - Added patch "block: Restrict the duration of sysfs attribute changes". - Remove queue freezing from more sysfs callbacks. block/blk-settings.c | 9 ++++++++- block/blk-sysfs.c | 30 ++++++++++++------------------ 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/block/blk-settings.c b/block/blk-settings.c index 78dfef117623..b5587cc535e5 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -23,7 +23,14 @@ void blk_queue_rq_timeout(struct request_queue *q, unsigned int timeout) { - WRITE_ONCE(q->rq_timeout, timeout); + /* + * Use WRITE_ONCE() to write q->rq_timeout once. Use data_race() to + * suppress KCSAN race reports against the write below. + */ + data_race(({ + WRITE_ONCE(q->rq_timeout, timeout); + 0; + })); } EXPORT_SYMBOL_GPL(blk_queue_rq_timeout); diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 76c47fe9b8d6..99e78d907c1c 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -143,21 +143,26 @@ queue_ra_store(struct gendisk *disk, const char *page, size_t count) { unsigned long ra_kb; ssize_t ret; - unsigned int memflags; struct request_queue *q = disk->queue; ret = queue_var_store(&ra_kb, page, count); if (ret < 0) return ret; /* - * ->ra_pages is protected by ->limits_lock because it is usually - * calculated from the queue limits by queue_limits_commit_update. + * The ->ra_pages change below is protected by ->limits_lock because it + * is usually calculated from the queue limits by + * queue_limits_commit_update(). + * + * bdi->ra_pages reads are not serialized against bdi->ra_pages writes. + * Use WRITE_ONCE() to write bdi->ra_pages once. Use data_race() to + * suppress KCSAN race reports against the write below. */ mutex_lock(&q->limits_lock); - memflags = blk_mq_freeze_queue(q); - disk->bdi->ra_pages = ra_kb >> (PAGE_SHIFT - 10); + data_race(({ + WRITE_ONCE(disk->bdi->ra_pages, ra_kb >> (PAGE_SHIFT - 10)); + 0; + })); mutex_unlock(&q->limits_lock); - blk_mq_unfreeze_queue(q, memflags); return ret; } @@ -375,21 +380,18 @@ static ssize_t queue_nomerges_store(struct gendisk *disk, const char *page, size_t count) { unsigned long nm; - unsigned int memflags; struct request_queue *q = disk->queue; ssize_t ret = queue_var_store(&nm, page, count); if (ret < 0) return ret; - memflags = blk_mq_freeze_queue(q); blk_queue_flag_clear(QUEUE_FLAG_NOMERGES, q); blk_queue_flag_clear(QUEUE_FLAG_NOXMERGES, q); if (nm == 2) blk_queue_flag_set(QUEUE_FLAG_NOMERGES, q); else if (nm) blk_queue_flag_set(QUEUE_FLAG_NOXMERGES, q); - blk_mq_unfreeze_queue(q, memflags); return ret; } @@ -409,7 +411,6 @@ queue_rq_affinity_store(struct gendisk *disk, const char *page, size_t count) #ifdef CONFIG_SMP struct request_queue *q = disk->queue; unsigned long val; - unsigned int memflags; ret = queue_var_store(&val, page, count); if (ret < 0) @@ -421,7 +422,6 @@ queue_rq_affinity_store(struct gendisk *disk, const char *page, size_t count) * are accessed individually using atomic test_bit operation. So we * don't grab any lock while updating these flags. */ - memflags = blk_mq_freeze_queue(q); if (val == 2) { blk_queue_flag_set(QUEUE_FLAG_SAME_COMP, q); blk_queue_flag_set(QUEUE_FLAG_SAME_FORCE, q); @@ -432,7 +432,6 @@ queue_rq_affinity_store(struct gendisk *disk, const char *page, size_t count) blk_queue_flag_clear(QUEUE_FLAG_SAME_COMP, q); blk_queue_flag_clear(QUEUE_FLAG_SAME_FORCE, q); } - blk_mq_unfreeze_queue(q, memflags); #endif return ret; } @@ -446,11 +445,9 @@ static ssize_t queue_poll_delay_store(struct gendisk *disk, const char *page, static ssize_t queue_poll_store(struct gendisk *disk, const char *page, size_t count) { - unsigned int memflags; ssize_t ret = count; struct request_queue *q = disk->queue; - memflags = blk_mq_freeze_queue(q); if (!(q->limits.features & BLK_FEAT_POLL)) { ret = -EINVAL; goto out; @@ -459,7 +456,6 @@ static ssize_t queue_poll_store(struct gendisk *disk, const char *page, pr_info_ratelimited("writes to the poll attribute are ignored.\n"); pr_info_ratelimited("please use driver specific parameters instead.\n"); out: - blk_mq_unfreeze_queue(q, memflags); return ret; } @@ -472,7 +468,7 @@ static ssize_t queue_io_timeout_show(struct gendisk *disk, char *page) static ssize_t queue_io_timeout_store(struct gendisk *disk, const char *page, size_t count) { - unsigned int val, memflags; + unsigned int val; int err; struct request_queue *q = disk->queue; @@ -480,9 +476,7 @@ static ssize_t queue_io_timeout_store(struct gendisk *disk, const char *page, if (err || val == 0) return -EINVAL; - memflags = blk_mq_freeze_queue(q); blk_queue_rq_timeout(q, msecs_to_jiffies(val)); - blk_mq_unfreeze_queue(q, memflags); return count; }

2 days, 20 hours

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror