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

FAILED: patch "[PATCH] cdc-acm: fix race between initial clearing halt and open" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 64690a90cd7c6db16d3af8616be1f4bf8d492850 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081847-user-synthesis-c726@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 64690a90cd7c6db16d3af8616be1f4bf8d492850 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 17 Jul 2025 16:12:50 +0200 Subject: [PATCH] cdc-acm: fix race between initial clearing halt and open On the devices that need their endpoints to get an initial clear_halt, this needs to be done before the devices can be opened. That means it needs to be before the devices are registered. Fixes: 15bf722e6f6c0 ("cdc-acm: Add support of ATOL FPrint fiscal printers") Cc: stable <stable(a)kernel.org> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Link: https://lore.kernel.org/r/20250717141259.2345605-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index c2ecfa3c8349..5a334e370f4d 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1520,6 +1520,12 @@ static int acm_probe(struct usb_interface *intf, goto err_remove_files; } + if (quirks & CLEAR_HALT_CONDITIONS) { + /* errors intentionally ignored */ + usb_clear_halt(usb_dev, acm->in); + usb_clear_halt(usb_dev, acm->out); + } + tty_dev = tty_port_register_device(&acm->port, acm_tty_driver, minor, &control_interface->dev); if (IS_ERR(tty_dev)) { @@ -1527,11 +1533,6 @@ static int acm_probe(struct usb_interface *intf, goto err_release_data_interface; } - if (quirks & CLEAR_HALT_CONDITIONS) { - usb_clear_halt(usb_dev, acm->in); - usb_clear_halt(usb_dev, acm->out); - } - dev_info(&intf->dev, "ttyACM%d: USB ACM device\n", minor); return 0;

1 week, 1 day

2
2
0 0

FAILED: patch "[PATCH] usb: typec: fusb302: cache PD RX state" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081835-swaddling-wound-cef8@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel <sebastian.reichel(a)collabora.com> Date: Fri, 4 Jul 2025 19:55:06 +0200 Subject: [PATCH] usb: typec: fusb302: cache PD RX state This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f2801279c4b5..a4ff2403ddd6 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -104,6 +104,7 @@ struct fusb302_chip { bool vconn_on; bool vbus_on; bool charge_on; + bool pd_rx_on; bool vbus_present; enum typec_cc_polarity cc_polarity; enum typec_cc_status cc1; @@ -841,6 +842,11 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) int ret = 0; mutex_lock(&chip->lock); + if (chip->pd_rx_on == on) { + fusb302_log(chip, "pd is already %s", str_on_off(on)); + goto done; + } + ret = fusb302_pd_rx_flush(chip); if (ret < 0) { fusb302_log(chip, "cannot flush pd rx buffer, ret=%d", ret); @@ -863,6 +869,8 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) str_on_off(on), ret); goto done; } + + chip->pd_rx_on = on; fusb302_log(chip, "pd := %s", str_on_off(on)); done: mutex_unlock(&chip->lock);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] cdc-acm: fix race between initial clearing halt and open" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 64690a90cd7c6db16d3af8616be1f4bf8d492850 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081847-resident-transform-fcca@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 64690a90cd7c6db16d3af8616be1f4bf8d492850 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 17 Jul 2025 16:12:50 +0200 Subject: [PATCH] cdc-acm: fix race between initial clearing halt and open On the devices that need their endpoints to get an initial clear_halt, this needs to be done before the devices can be opened. That means it needs to be before the devices are registered. Fixes: 15bf722e6f6c0 ("cdc-acm: Add support of ATOL FPrint fiscal printers") Cc: stable <stable(a)kernel.org> Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Link: https://lore.kernel.org/r/20250717141259.2345605-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index c2ecfa3c8349..5a334e370f4d 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1520,6 +1520,12 @@ static int acm_probe(struct usb_interface *intf, goto err_remove_files; } + if (quirks & CLEAR_HALT_CONDITIONS) { + /* errors intentionally ignored */ + usb_clear_halt(usb_dev, acm->in); + usb_clear_halt(usb_dev, acm->out); + } + tty_dev = tty_port_register_device(&acm->port, acm_tty_driver, minor, &control_interface->dev); if (IS_ERR(tty_dev)) { @@ -1527,11 +1533,6 @@ static int acm_probe(struct usb_interface *intf, goto err_release_data_interface; } - if (quirks & CLEAR_HALT_CONDITIONS) { - usb_clear_halt(usb_dev, acm->in); - usb_clear_halt(usb_dev, acm->out); - } - dev_info(&intf->dev, "ttyACM%d: USB ACM device\n", minor); return 0;

1 week, 1 day

2
2
0 0

FAILED: patch "[PATCH] usb: typec: fusb302: cache PD RX state" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081834-staff-ranged-09c8@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel <sebastian.reichel(a)collabora.com> Date: Fri, 4 Jul 2025 19:55:06 +0200 Subject: [PATCH] usb: typec: fusb302: cache PD RX state This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f2801279c4b5..a4ff2403ddd6 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -104,6 +104,7 @@ struct fusb302_chip { bool vconn_on; bool vbus_on; bool charge_on; + bool pd_rx_on; bool vbus_present; enum typec_cc_polarity cc_polarity; enum typec_cc_status cc1; @@ -841,6 +842,11 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) int ret = 0; mutex_lock(&chip->lock); + if (chip->pd_rx_on == on) { + fusb302_log(chip, "pd is already %s", str_on_off(on)); + goto done; + } + ret = fusb302_pd_rx_flush(chip); if (ret < 0) { fusb302_log(chip, "cannot flush pd rx buffer, ret=%d", ret); @@ -863,6 +869,8 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) str_on_off(on), ret); goto done; } + + chip->pd_rx_on = on; fusb302_log(chip, "pd := %s", str_on_off(on)); done: mutex_unlock(&chip->lock);

1 week, 1 day

2
1
0 0

[PATCH 6.15 00/92] 6.15.9-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.15.9 release. There are 92 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri, 01 Aug 2025 09:32:07 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.9-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.15.9-rc1 Daniel Dadap <ddadap(a)nvidia.com> ALSA: hda: Add missing NVIDIA HDA codec IDs Mohan Kumar D <mkumard(a)nvidia.com> ALSA: hda/tegra: Add Tegra264 support Khairul Anuar Romli <khairul.anuar.romli(a)altera.com> spi: cadence-quadspi: fix cleanup of rx_chan on failure paths RD Babiera <rdbabiera(a)google.com> usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach Michael Grzeschik <m.grzeschik(a)pengutronix.de> usb: typec: tcpm: allow switching to mode accessory to mux properly Michael Grzeschik <m.grzeschik(a)pengutronix.de> usb: typec: tcpm: allow to use sink in accessory mode Thomas Zimmermann <tzimmermann(a)suse.de> Revert "drm/gem-shmem: Use dma_buf from GEM object instance" Dmitry Osipenko <dmitry.osipenko(a)collabora.com> drm/shmem-helper: Remove obsoleted is_iomem test Jesse Zhang <jesse.zhang(a)amd.com> drm/amdgpu: Fix SDMA engine reset with logical instance ID Jesse.zhang(a)amd.com <Jesse.zhang(a)amd.com> drm/amdgpu: Implement SDMA soft reset directly for v5.x Jesse.zhang(a)amd.com <Jesse.zhang(a)amd.com> drm/amdgpu: Add the new sdma function pointers for amdgpu_sdma.h Matthew Brost <matthew.brost(a)intel.com> drm/xe: Make WA BB part of LRC BO Yonghong Song <yonghong.song(a)linux.dev> selftests/bpf: Add tests with stack ptr register in conditional jmp Harry Yoo <harry.yoo(a)oracle.com> mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n Jinjiang Tu <tujinjiang(a)huawei.com> mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list Zi Yan <ziy(a)nvidia.com> selftests/mm: fix split_huge_page_test for folio_split() tests Matthieu Baerts (NGI0) <matttbe(a)kernel.org> selftests: mptcp: connect: also cover checksum Matthieu Baerts (NGI0) <matttbe(a)kernel.org> selftests: mptcp: connect: also cover alt modes Akinobu Mita <akinobu.mita(a)gmail.com> resource: fix false warning in __request_region() Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> PCI/pwrctrl: Create pwrctrl devices only when CONFIG_PCI_PWRCTRL is enabled Ryusuke Konishi <konishi.ryusuke(a)gmail.com> nilfs2: reject invalid file types when reading inodes Marco Elver <elver(a)google.com> kasan: use vmalloc_dump_obj() for vmalloc error reports Haoxiang Li <haoxiang_li2024(a)163.com> ice: Fix a null pointer dereference in ice_copy_and_init_pkg() Praveen Kaligineedi <pkaligineedi(a)google.com> gve: Fix stuck TX queue for DQ queue format Jacek Kowalski <jacek(a)jacekk.info> e1000e: ignore uninitialized checksum word on tgp Jacek Kowalski <jacek(a)jacekk.info> e1000e: disregard NVM checksum on tgp when valid checksum bit is not set Ma Ke <make24(a)iscas.ac.cn> dpaa2-switch: Fix device reference count leak in MAC endpoint handling Ma Ke <make24(a)iscas.ac.cn> dpaa2-eth: Fix device reference count leak in MAC endpoint handling Johan Hovold <johan(a)kernel.org> ASoC: mediatek: common: fix device and OF node leak Ada Couprie Diaz <ada.coupriediaz(a)arm.com> arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() Edip Hazuri <edip(a)medip.dev> ALSA: hda/realtek - Add mute LED support for HP Victus 15-fa0xxx Dawid Rezler <dawidrezler.patches(a)gmail.com> ALSA: hda/realtek - Add mute LED support for HP Pavilion 15-eg0xxx Stephen Rothwell <sfr(a)canb.auug.org.au> sprintf.h requires stdarg.h Ma Ke <make24(a)iscas.ac.cn> bus: fsl-mc: Fix potential double device reference in fsl_mc_get_endpoint() Viresh Kumar <viresh.kumar(a)linaro.org> i2c: virtio: Avoid hang by using interruptible completion wait Akhil R <akhilrajeev(a)nvidia.com> i2c: tegra: Fix reset error handling with ACPI Yang Xiwen <forbidden405(a)outlook.com> i2c: qup: jump out of the loop in case of timeout Markus Blöchl <markus(a)blochl.de> timekeeping: Zero initialize system_counterval when querying time from phc drivers Nathan Chancellor <nathan(a)kernel.org> ARM: 9450/1: Fix allowing linker DCE with binutils < 2.36 Nathan Chancellor <nathan(a)kernel.org> ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS Nathan Chancellor <nathan(a)kernel.org> mm/ksm: fix -Wsometimes-uninitialized from clang-21 in advisor_mode_show() Lin.Cao <lincao12(a)amd.com> drm/sched: Remove optimization that causes hang when killing dependent jobs Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam(a)amd.com> drm/amdgpu: Reset the clear flag in buddy during resume Thomas Zimmermann <tzimmermann(a)suse.de> Revert "drm/gem-dma: Use dma_buf from GEM object instance" Thomas Zimmermann <tzimmermann(a)suse.de> Revert "drm/gem-framebuffer: Use dma_buf from GEM object instance" Thomas Zimmermann <tzimmermann(a)suse.de> Revert "drm/prime: Use dma_buf from GEM object instance" Ville Syrjälä <ville.syrjala(a)linux.intel.com> drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x Rong Zhang <i(a)rong.moe> platform/x86: ideapad-laptop: Fix kbd backlight not remembered among boots Rong Zhang <i(a)rong.moe> platform/x86: ideapad-laptop: Fix FnLock not remembered among boots Kurt Borja <kuurtb(a)gmail.com> platform/x86: alienware-wmi-wmax: Fix `dmi_system_id` array Jijie Shao <shaojijie(a)huawei.com> net: hns3: default enable tx bounce buffer when smmu enabled Jian Shen <shenjian15(a)huawei.com> net: hns3: fixed vf get max channels bug Yonglong Liu <liuyonglong(a)huawei.com> net: hns3: disable interrupt when ptp init failed Jian Shen <shenjian15(a)huawei.com> net: hns3: fix concurrent setting vlan filter issue Halil Pasic <pasic(a)linux.ibm.com> s390/ism: fix concurrency management in ism_cmd() Nimrod Oren <noren(a)nvidia.com> selftests: drv-net: wait for iperf client to stop sending SHARAN KUMAR M <sharweshraajan(a)gmail.com> ALSA: hda/realtek: Fix mute LED mask on HP OMEN 16 laptop Douglas Anderson <dianders(a)chromium.org> drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe() Marc Kleine-Budde <mkl(a)pengutronix.de> can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode Xiang Mei <xmei5(a)asu.edu> net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class Kito Xu (veritas501) <hxzene(a)gmail.com> net: appletalk: Fix use-after-free in AARP proxy probe Jamie Bainbridge <jamie.bainbridge(a)gmail.com> i40e: When removing VF MAC filters, only check PF-set MAC Dennis Chen <dechen(a)redhat.com> i40e: report VF tx_dropped with tx_errors instead of tx_discards Shahar Shitrit <shshitrit(a)nvidia.com> net/mlx5: E-Switch, Fix peer miss rules to use peer eswitch Chiara Meiohas <cmeiohas(a)nvidia.com> net/mlx5: Fix memory leak in cmd_exec() Himanshu Mittal <h-mittal1(a)ti.com> net: ti: icssg-prueth: Fix buffer allocation for ICSSG Guoqing Jiang <guoqing.jiang(a)canonical.com> ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv Eyal Birger <eyal.birger(a)gmail.com> xfrm: interface: fix use-after-free after changing collect_md xfrm interface Fernando Fernandez Mancera <fmancera(a)suse.de> xfrm: ipcomp: adjust transport header after decompressing Tobias Brunner <tobias(a)strongswan.org> xfrm: Set transport header to fix UDP GRO handling Leon Romanovsky <leon(a)kernel.org> xfrm: always initialize offload path Sabrina Dubroca <sd(a)queasysnail.net> xfrm: state: use a consistent pcpu_id in xfrm_state_find Sabrina Dubroca <sd(a)queasysnail.net> xfrm: state: initialize state_ptrs earlier in xfrm_state_find Stefan Wahren <wahrenst(a)gmx.net> staging: vchiq_arm: Make vchiq_shutdown never fail Torsten Hilbrich <torsten.hilbrich(a)secunet.com> platform/x86: Fix initialization order for firmware_attributes_class Nuno Das Neves <nunodasneves(a)linux.microsoft.com> x86/hyperv: Fix usage of cpu_online_mask to get valid cpu Yasumasa Suenaga <yasuenag(a)gmail.com> tools/hv: fcopy: Fix incorrect file path conversion Shravan Kumar Ramani <shravankr(a)nvidia.com> platform/mellanox: mlxbf-pmc: Use kstrtobool() to check 0/1 input Shravan Kumar Ramani <shravankr(a)nvidia.com> platform/mellanox: mlxbf-pmc: Validate event/enable input Shravan Kumar Ramani <shravankr(a)nvidia.com> platform/mellanox: mlxbf-pmc: Remove newline char from event name input Abdun Nihaal <abdun.nihaal(a)gmail.com> regmap: fix potential memory leak of regmap_bus David Lechner <dlechner(a)baylibre.com> iio: adc: ad7949: use spi_is_bpw_supported() Gabor Juhos <j4g8y7(a)gmail.com> interconnect: icc-clk: destroy nodes in case of memory allocation failures Xilin Wu <sophon(a)radxa.com> interconnect: qcom: sc7280: Add missing num_links to xm_pcie3_1 node Markus Burri <markus.burri(a)mt.com> iio: fix potential out-of-bound write Maor Gottlieb <maorg(a)nvidia.com> RDMA/core: Rate limit GID cache warning messages Rahul Chandra <rahul(a)chandra.net> platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8406CA Alessandro Carminati <acarmina(a)redhat.com> regulator: core: fix NULL dereference on unbind due to stale coupling data Mario Limonciello <mario.limonciello(a)amd.com> drm/amd/display: Don't allow OLED to go down to fully off Laurent Vivier <lvivier(a)redhat.com> virtio_ring: Fix error reporting in virtqueue_resize Laurent Vivier <lvivier(a)redhat.com> virtio_net: Enforce minimum TX ring size for reliability Xin Li (Intel) <xin(a)zytor.com> x86/traps: Initialize DR7 by writing its architectural reset value ------------- Diffstat: Makefile | 4 +- arch/arm/Kconfig | 2 +- arch/arm/Makefile | 2 +- arch/arm64/include/asm/assembler.h | 5 + arch/arm64/kernel/entry.S | 6 + arch/x86/hyperv/irqdomain.c | 4 +- arch/x86/include/asm/debugreg.h | 19 ++- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/kgdb.c | 2 +- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- arch/x86/kvm/x86.c | 4 +- drivers/base/regmap/regmap.c | 2 + drivers/bus/fsl-mc/fsl-mc-bus.c | 19 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 44 +++++- drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/drm_buddy.c | 43 ++++++ drivers/gpu/drm/drm_gem_dma_helper.c | 2 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 8 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 10 +- drivers/gpu/drm/drm_prime.c | 8 +- drivers/gpu/drm/i915/display/intel_dp.c | 6 + drivers/gpu/drm/scheduler/sched_entity.c | 21 +-- drivers/gpu/drm/xe/xe_lrc.c | 37 ++--- drivers/gpu/drm/xe/xe_lrc_types.h | 3 - drivers/i2c/busses/i2c-qup.c | 4 +- drivers/i2c/busses/i2c-tegra.c | 24 +-- drivers/i2c/busses/i2c-virtio.c | 15 +- drivers/iio/adc/ad7949.c | 7 +- drivers/iio/industrialio-core.c | 5 +- drivers/infiniband/core/cache.c | 4 +- drivers/interconnect/icc-clk.c | 2 + drivers/interconnect/qcom/sc7280.c | 1 + drivers/net/can/dev/dev.c | 12 +- drivers/net/can/dev/netlink.c | 12 ++ drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 15 +- .../net/ethernet/freescale/dpaa2/dpaa2-switch.c | 15 +- drivers/net/ethernet/google/gve/gve_main.c | 67 +++++---- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 31 ++++ drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 36 +++-- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c | 9 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 6 +- drivers/net/ethernet/intel/e1000e/defines.h | 3 + drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 + drivers/net/ethernet/intel/e1000e/nvm.c | 6 + drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 6 +- drivers/net/ethernet/intel/ice/ice_ddp.c | 2 + drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 4 +- .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 108 +++++++------- drivers/net/ethernet/ti/icssg/icssg_config.c | 162 ++++++++++++++------- drivers/net/ethernet/ti/icssg/icssg_config.h | 78 ++++++++-- drivers/net/ethernet/ti/icssg/icssg_prueth.c | 20 ++- drivers/net/ethernet/ti/icssg/icssg_prueth.h | 2 + drivers/net/ethernet/ti/icssg/icssg_switch_map.h | 3 + drivers/net/virtio_net.c | 6 + drivers/pci/probe.c | 7 + drivers/platform/mellanox/mlxbf-pmc.c | 25 +++- drivers/platform/x86/Makefile | 3 +- drivers/platform/x86/asus-nb-wmi.c | 9 ++ drivers/platform/x86/dell/alienware-wmi-wmax.c | 1 + drivers/platform/x86/ideapad-laptop.c | 4 +- drivers/regulator/core.c | 1 + drivers/s390/net/ism_drv.c | 3 + drivers/spi/spi-cadence-quadspi.c | 5 - .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 +- drivers/usb/typec/tcpm/tcpm.c | 64 ++++---- drivers/virtio/virtio_ring.c | 8 +- fs/nilfs2/inode.c | 9 +- include/drm/drm_buddy.h | 2 + include/linux/ism.h | 1 + include/linux/sprintf.h | 1 + include/net/xfrm.h | 2 +- kernel/bpf/verifier.c | 7 +- kernel/resource.c | 5 +- kernel/time/timekeeping.c | 2 +- mm/kasan/report.c | 4 +- mm/ksm.c | 6 +- mm/memory-failure.c | 4 + mm/vmscan.c | 8 + mm/zsmalloc.c | 3 + net/appletalk/aarp.c | 24 ++- net/ipv4/xfrm4_input.c | 3 + net/ipv6/xfrm6_input.c | 3 + net/sched/sch_qfq.c | 7 +- net/xfrm/xfrm_device.c | 1 - net/xfrm/xfrm_interface_core.c | 7 +- net/xfrm/xfrm_ipcomp.c | 2 +- net/xfrm/xfrm_state.c | 29 ++-- net/xfrm/xfrm_user.c | 1 + sound/pci/hda/hda_tegra.c | 51 ++++++- sound/pci/hda/patch_hdmi.c | 20 +++ sound/pci/hda/patch_realtek.c | 4 +- sound/soc/mediatek/common/mtk-soundcard-driver.c | 4 + sound/soc/mediatek/mt8365/mt8365-dai-i2s.c | 3 +- tools/hv/hv_fcopy_uio_daemon.c | 37 ++--- .../selftests/bpf/progs/verifier_precision.c | 53 +++++++ tools/testing/selftests/drivers/net/lib/py/load.py | 23 ++- tools/testing/selftests/mm/split_huge_page_test.c | 3 +- tools/testing/selftests/net/mptcp/Makefile | 3 +- .../selftests/net/mptcp/mptcp_connect_checksum.sh | 5 + .../selftests/net/mptcp/mptcp_connect_mmap.sh | 5 + .../selftests/net/mptcp/mptcp_connect_sendfile.sh | 5 + 109 files changed, 998 insertions(+), 452 deletions(-)

1 week, 1 day

15
107
0 0

FAILED: patch "[PATCH] usb: typec: fusb302: cache PD RX state" 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 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081833-chatting-dragging-a84b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel <sebastian.reichel(a)collabora.com> Date: Fri, 4 Jul 2025 19:55:06 +0200 Subject: [PATCH] usb: typec: fusb302: cache PD RX state This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f2801279c4b5..a4ff2403ddd6 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -104,6 +104,7 @@ struct fusb302_chip { bool vconn_on; bool vbus_on; bool charge_on; + bool pd_rx_on; bool vbus_present; enum typec_cc_polarity cc_polarity; enum typec_cc_status cc1; @@ -841,6 +842,11 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) int ret = 0; mutex_lock(&chip->lock); + if (chip->pd_rx_on == on) { + fusb302_log(chip, "pd is already %s", str_on_off(on)); + goto done; + } + ret = fusb302_pd_rx_flush(chip); if (ret < 0) { fusb302_log(chip, "cannot flush pd rx buffer, ret=%d", ret); @@ -863,6 +869,8 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) str_on_off(on), ret); goto done; } + + chip->pd_rx_on = on; fusb302_log(chip, "pd := %s", str_on_off(on)); done: mutex_unlock(&chip->lock);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081849-trio-prepay-4247@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

[PATCH net-next v3 2/5] sctp: Fix MAC comparison to be constant-time

by Eric Biggers

To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- net/sctp/sm_make_chunk.c | 3 ++- net/sctp/sm_statefuns.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 3ead591c72fd3..d099b605e44a7 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -29,10 +29,11 @@ */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <crypto/hash.h> +#include <crypto/utils.h> #include <linux/types.h> #include <linux/kernel.h> #include <linux/ip.h> #include <linux/ipv6.h> #include <linux/net.h> @@ -1786,11 +1787,11 @@ struct sctp_association *sctp_unpack_cookie( *error = -SCTP_IERROR_NOMEM; goto fail; } } - if (memcmp(digest, cookie->signature, SCTP_SIGNATURE_SIZE)) { + if (crypto_memneq(digest, cookie->signature, SCTP_SIGNATURE_SIZE)) { *error = -SCTP_IERROR_BAD_SIG; goto fail; } no_hmac: diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index a0524ba8d7878..d4d5b14b49b3f 100644 --- a/net/sctp/sm_statefuns.c +++ b/net/sctp/sm_statefuns.c @@ -28,10 +28,11 @@ * Kevin Gao <kevin.gao(a)intel.com> */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <crypto/utils.h> #include <linux/types.h> #include <linux/kernel.h> #include <linux/ip.h> #include <linux/ipv6.h> #include <linux/net.h> @@ -4414,11 +4415,11 @@ static enum sctp_ierror sctp_sf_authenticate( sctp_auth_calculate_hmac(asoc, chunk->skb, (struct sctp_auth_chunk *)chunk->chunk_hdr, sh_key, GFP_ATOMIC); /* Discard the packet if the digests do not match */ - if (memcmp(save_digest, digest, sig_len)) { + if (crypto_memneq(save_digest, digest, sig_len)) { kfree(save_digest); return SCTP_IERROR_BAD_SIG; } kfree(save_digest); -- 2.50.1

1 week, 1 day

1
0
0 0

FAILED: patch "[PATCH] usb: typec: fusb302: cache PD RX state" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081832-rental-utter-f3e1@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel <sebastian.reichel(a)collabora.com> Date: Fri, 4 Jul 2025 19:55:06 +0200 Subject: [PATCH] usb: typec: fusb302: cache PD RX state This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f2801279c4b5..a4ff2403ddd6 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -104,6 +104,7 @@ struct fusb302_chip { bool vconn_on; bool vbus_on; bool charge_on; + bool pd_rx_on; bool vbus_present; enum typec_cc_polarity cc_polarity; enum typec_cc_status cc1; @@ -841,6 +842,11 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) int ret = 0; mutex_lock(&chip->lock); + if (chip->pd_rx_on == on) { + fusb302_log(chip, "pd is already %s", str_on_off(on)); + goto done; + } + ret = fusb302_pd_rx_flush(chip); if (ret < 0) { fusb302_log(chip, "cannot flush pd rx buffer, ret=%d", ret); @@ -863,6 +869,8 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) str_on_off(on), ret); goto done; } + + chip->pd_rx_on = on; fusb302_log(chip, "pd := %s", str_on_off(on)); done: mutex_unlock(&chip->lock);

1 week, 1 day

2
1
0 0

[PATCH net-next 1/3] ipv6: sr: Fix MAC comparison to be constant-time

by Eric Biggers

To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- net/ipv6/seg6_hmac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c index f78ecb6ad8383..5dae892bbc73b 100644 --- a/net/ipv6/seg6_hmac.c +++ b/net/ipv6/seg6_hmac.c @@ -33,10 +33,11 @@ #include <net/ip6_route.h> #include <net/addrconf.h> #include <net/xfrm.h> #include <crypto/hash.h> +#include <crypto/utils.h> #include <net/seg6.h> #include <net/genetlink.h> #include <net/seg6_hmac.h> #include <linux/random.h> @@ -278,11 +279,11 @@ bool seg6_hmac_validate_skb(struct sk_buff *skb) return false; if (seg6_hmac_compute(hinfo, srh, &ipv6_hdr(skb)->saddr, hmac_output)) return false; - if (memcmp(hmac_output, tlv->hmac, SEG6_HMAC_FIELD_LEN) != 0) + if (crypto_memneq(hmac_output, tlv->hmac, SEG6_HMAC_FIELD_LEN)) return false; return true; } EXPORT_SYMBOL(seg6_hmac_validate_skb); -- 2.50.1

1 week, 1 day

2
3
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081848-lemon-attic-be0e@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] usb: typec: fusb302: cache PD RX state" 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 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081831-untrimmed-dab-6b43@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel <sebastian.reichel(a)collabora.com> Date: Fri, 4 Jul 2025 19:55:06 +0200 Subject: [PATCH] usb: typec: fusb302: cache PD RX state This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f2801279c4b5..a4ff2403ddd6 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -104,6 +104,7 @@ struct fusb302_chip { bool vconn_on; bool vbus_on; bool charge_on; + bool pd_rx_on; bool vbus_present; enum typec_cc_polarity cc_polarity; enum typec_cc_status cc1; @@ -841,6 +842,11 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) int ret = 0; mutex_lock(&chip->lock); + if (chip->pd_rx_on == on) { + fusb302_log(chip, "pd is already %s", str_on_off(on)); + goto done; + } + ret = fusb302_pd_rx_flush(chip); if (ret < 0) { fusb302_log(chip, "cannot flush pd rx buffer, ret=%d", ret); @@ -863,6 +869,8 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) str_on_off(on), ret); goto done; } + + chip->pd_rx_on = on; fusb302_log(chip, "pd := %s", str_on_off(on)); done: mutex_unlock(&chip->lock);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" 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 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081848-charter-handcart-4eda@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081847-cheddar-glacier-ea0e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" 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 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081846-exquisite-previous-f76e@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] usb: typec: fusb302: cache PD RX state" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081830-selected-dandelion-46ec@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel <sebastian.reichel(a)collabora.com> Date: Fri, 4 Jul 2025 19:55:06 +0200 Subject: [PATCH] usb: typec: fusb302: cache PD RX state This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f2801279c4b5..a4ff2403ddd6 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -104,6 +104,7 @@ struct fusb302_chip { bool vconn_on; bool vbus_on; bool charge_on; + bool pd_rx_on; bool vbus_present; enum typec_cc_polarity cc_polarity; enum typec_cc_status cc1; @@ -841,6 +842,11 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) int ret = 0; mutex_lock(&chip->lock); + if (chip->pd_rx_on == on) { + fusb302_log(chip, "pd is already %s", str_on_off(on)); + goto done; + } + ret = fusb302_pd_rx_flush(chip); if (ret < 0) { fusb302_log(chip, "cannot flush pd rx buffer, ret=%d", ret); @@ -863,6 +869,8 @@ static int tcpm_set_pd_rx(struct tcpc_dev *dev, bool on) str_on_off(on), ret); goto done; } + + chip->pd_rx_on = on; fusb302_log(chip, "pd := %s", str_on_off(on)); done: mutex_unlock(&chip->lock);

1 week, 1 day

2
2
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081846-vanquish-fastball-b7d1@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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-6.15.y git checkout FETCH_HEAD git cherry-pick -x 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081845-enlarging-goldsmith-455a@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] serial: 8250: fix panic due to PSLVERR" failed to apply to 6.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.16-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.16.y git checkout FETCH_HEAD git cherry-pick -x 7f8fdd4dbffc05982b96caf586f77a014b2a9353 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081844-wimp-jubilance-539e@gregkh' --subject-prefix 'PATCH 6.16.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7f8fdd4dbffc05982b96caf586f77a014b2a9353 Mon Sep 17 00:00:00 2001 From: Yunhui Cui <cuiyunhui(a)bytedance.com> Date: Wed, 23 Jul 2025 10:33:22 +0800 Subject: [PATCH] serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> Reviewed-by: John Ogness <john.ogness(a)linutronix.de> Cc: stable <stable(a)kernel.org> Link: https://lore.kernel.org/r/20250723023322.464-2-cuiyunhui@bytedance.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 7eddcab318b4..2da9db960d09 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2269,9 +2269,9 @@ static void serial8250_initialize(struct uart_port *port) { unsigned long flags; + uart_port_lock_irqsave(port, &flags); serial_port_out(port, UART_LCR, UART_LCR_WLEN8); - uart_port_lock_irqsave(port, &flags); serial8250_init_mctrl(port); serial8250_iir_txen_test(port); uart_port_unlock_irqrestore(port, flags);

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] cifs: reset iface weights when we cannot find a candidate" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 9d5eff7821f6d70f7d1b4d8a60680fba4de868a7 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081845-cork-enable-a1e8@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9d5eff7821f6d70f7d1b4d8a60680fba4de868a7 Mon Sep 17 00:00:00 2001 From: Shyam Prasad N <sprasad(a)microsoft.com> Date: Thu, 17 Jul 2025 17:36:13 +0530 Subject: [PATCH] cifs: reset iface weights when we cannot find a candidate We now do a weighted selection of server interfaces when allocating new channels. The weights are decided based on the speed advertised. The fulfilled weight for an interface is a counter that is used to track the interface selection. It should be reset back to zero once all interfaces fulfilling their weight. In cifs_chan_update_iface, this reset logic was missing. As a result when the server interface list changes, the client may not be able to find a new candidate for other channels after all interfaces have been fulfilled. Fixes: a6d8fb54a515 ("cifs: distribute channels across interfaces based on speed") Cc: <stable(a)vger.kernel.org> Signed-off-by: Shyam Prasad N <sprasad(a)microsoft.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/sess.c b/fs/smb/client/sess.c index 330bc3d25bad..0a8c2fcc9ded 100644 --- a/fs/smb/client/sess.c +++ b/fs/smb/client/sess.c @@ -332,6 +332,7 @@ cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server) struct cifs_server_iface *old_iface = NULL; struct cifs_server_iface *last_iface = NULL; struct sockaddr_storage ss; + int retry = 0; spin_lock(&ses->chan_lock); chan_index = cifs_ses_get_chan_index(ses, server); @@ -360,6 +361,7 @@ cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server) return; } +try_again: last_iface = list_last_entry(&ses->iface_list, struct cifs_server_iface, iface_head); iface_min_speed = last_iface->speed; @@ -397,6 +399,13 @@ cifs_chan_update_iface(struct cifs_ses *ses, struct TCP_Server_Info *server) } if (list_entry_is_head(iface, &ses->iface_list, iface_head)) { + list_for_each_entry(iface, &ses->iface_list, iface_head) + iface->weight_fulfilled = 0; + + /* see if it can be satisfied in second attempt */ + if (!retry++) + goto try_again; + iface = NULL; cifs_dbg(FYI, "unable to find a suitable iface\n"); }

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] mm/damon/ops-common: ignore migration request to invalid" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 7e6c3130690a01076efdf45aa02ba5d5c16849a0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081833-booting-yelling-d0fa@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7e6c3130690a01076efdf45aa02ba5d5c16849a0 Mon Sep 17 00:00:00 2001 From: SeongJae Park <sj(a)kernel.org> Date: Sun, 20 Jul 2025 11:58:22 -0700 Subject: [PATCH] mm/damon/ops-common: ignore migration request to invalid nodes damon_migrate_pages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests via DAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen. [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405) [...] Add a target node validity check in damon_migrate_pages(). The validity check is stolen from that of do_pages_move(), which is being used for the move_pages() system call. Link: https://lkml.kernel.org/r/20250720185822.1451-1-sj@kernel.org Fixes: b51820ebea65 ("mm/damon/paddr: introduce DAMOS_MIGRATE_COLD action for demotion") [6.11.x] Signed-off-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: Joshua Hahn <joshua.hahnjy(a)gmail.com> Cc: Honggyu Kim <honggyu.kim(a)sk.com> Cc: Hyeongtak Ji <hyeongtak.ji(a)sk.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c index 6a9797d1d7ff..99321ff5cb92 100644 --- a/mm/damon/ops-common.c +++ b/mm/damon/ops-common.c @@ -383,6 +383,10 @@ unsigned long damon_migrate_pages(struct list_head *folio_list, int target_nid) if (list_empty(folio_list)) return nr_migrated; + if (target_nid < 0 || target_nid >= MAX_NUMNODES || + !node_state(target_nid, N_MEMORY)) + return nr_migrated; + noreclaim_flag = memalloc_noreclaim_save(); nid = folio_nid(lru_to_folio(folio_list));

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] mm/damon/ops-common: ignore migration request to invalid" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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-6.15.y git checkout FETCH_HEAD git cherry-pick -x 7e6c3130690a01076efdf45aa02ba5d5c16849a0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081832-splendor-carve-f25b@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7e6c3130690a01076efdf45aa02ba5d5c16849a0 Mon Sep 17 00:00:00 2001 From: SeongJae Park <sj(a)kernel.org> Date: Sun, 20 Jul 2025 11:58:22 -0700 Subject: [PATCH] mm/damon/ops-common: ignore migration request to invalid nodes damon_migrate_pages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests via DAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen. [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405) [...] Add a target node validity check in damon_migrate_pages(). The validity check is stolen from that of do_pages_move(), which is being used for the move_pages() system call. Link: https://lkml.kernel.org/r/20250720185822.1451-1-sj@kernel.org Fixes: b51820ebea65 ("mm/damon/paddr: introduce DAMOS_MIGRATE_COLD action for demotion") [6.11.x] Signed-off-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: Joshua Hahn <joshua.hahnjy(a)gmail.com> Cc: Honggyu Kim <honggyu.kim(a)sk.com> Cc: Hyeongtak Ji <hyeongtak.ji(a)sk.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c index 6a9797d1d7ff..99321ff5cb92 100644 --- a/mm/damon/ops-common.c +++ b/mm/damon/ops-common.c @@ -383,6 +383,10 @@ unsigned long damon_migrate_pages(struct list_head *folio_list, int target_nid) if (list_empty(folio_list)) return nr_migrated; + if (target_nid < 0 || target_nid >= MAX_NUMNODES || + !node_state(target_nid, N_MEMORY)) + return nr_migrated; + noreclaim_flag = memalloc_noreclaim_save(); nid = folio_nid(lru_to_folio(folio_list));

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] mm/damon/ops-common: ignore migration request to invalid" failed to apply to 6.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.16-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.16.y git checkout FETCH_HEAD git cherry-pick -x 7e6c3130690a01076efdf45aa02ba5d5c16849a0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081831-singular-geologist-93a6@gregkh' --subject-prefix 'PATCH 6.16.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7e6c3130690a01076efdf45aa02ba5d5c16849a0 Mon Sep 17 00:00:00 2001 From: SeongJae Park <sj(a)kernel.org> Date: Sun, 20 Jul 2025 11:58:22 -0700 Subject: [PATCH] mm/damon/ops-common: ignore migration request to invalid nodes damon_migrate_pages() tries migration even if the target node is invalid. If users mistakenly make such invalid requests via DAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen. [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48 [ 7831.884160] #PF: supervisor read access in kernel mode [ 7831.884681] #PF: error_code(0x0000) - not-present page [ 7831.885203] PGD 0 P4D 0 [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary) [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014 [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137) [...] [ 7831.895953] Call Trace: [ 7831.896195] <TASK> [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192) [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851) [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.897735] migrate_pages (mm/migrate.c:2078) [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137) [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354) [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405) [...] Add a target node validity check in damon_migrate_pages(). The validity check is stolen from that of do_pages_move(), which is being used for the move_pages() system call. Link: https://lkml.kernel.org/r/20250720185822.1451-1-sj@kernel.org Fixes: b51820ebea65 ("mm/damon/paddr: introduce DAMOS_MIGRATE_COLD action for demotion") [6.11.x] Signed-off-by: SeongJae Park <sj(a)kernel.org> Reviewed-by: Joshua Hahn <joshua.hahnjy(a)gmail.com> Cc: Honggyu Kim <honggyu.kim(a)sk.com> Cc: Hyeongtak Ji <hyeongtak.ji(a)sk.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c index 6a9797d1d7ff..99321ff5cb92 100644 --- a/mm/damon/ops-common.c +++ b/mm/damon/ops-common.c @@ -383,6 +383,10 @@ unsigned long damon_migrate_pages(struct list_head *folio_list, int target_nid) if (list_empty(folio_list)) return nr_migrated; + if (target_nid < 0 || target_nid >= MAX_NUMNODES || + !node_state(target_nid, N_MEMORY)) + return nr_migrated; + noreclaim_flag = memalloc_noreclaim_save(); nid = folio_nid(lru_to_folio(folio_list));

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] io_uring/zcrx: account area memory" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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-6.15.y git checkout FETCH_HEAD git cherry-pick -x 262ab205180d2ba3ab6110899a4dbe439c51dfaa # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081527-unflawed-matrimony-2057@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 262ab205180d2ba3ab6110899a4dbe439c51dfaa Mon Sep 17 00:00:00 2001 From: Pavel Begunkov <asml.silence(a)gmail.com> Date: Wed, 16 Jul 2025 22:04:09 +0100 Subject: [PATCH] io_uring/zcrx: account area memory zcrx areas can be quite large and need to be accounted and checked against RLIMIT_MEMLOCK. In practise it shouldn't be a big issue as the inteface already requires cap_net_admin. Cc: stable(a)vger.kernel.org Fixes: cf96310c5f9a0 ("io_uring/zcrx: add io_zcrx_area") Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Link: https://lore.kernel.org/r/4b53f0c575bd062f63d12bec6cac98037fc66aeb.17526995… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c index 7d7396ce876c..dabce3ee0e8b 100644 --- a/io_uring/zcrx.c +++ b/io_uring/zcrx.c @@ -158,6 +158,23 @@ static int io_zcrx_map_area_dmabuf(struct io_zcrx_ifq *ifq, struct io_zcrx_area area->mem.dmabuf_offset); } +static unsigned long io_count_account_pages(struct page **pages, unsigned nr_pages) +{ + struct folio *last_folio = NULL; + unsigned long res = 0; + int i; + + for (i = 0; i < nr_pages; i++) { + struct folio *folio = page_folio(pages[i]); + + if (folio == last_folio) + continue; + last_folio = folio; + res += 1UL << folio_order(folio); + } + return res; +} + static int io_import_umem(struct io_zcrx_ifq *ifq, struct io_zcrx_mem *mem, struct io_uring_zcrx_area_reg *area_reg) @@ -180,6 +197,13 @@ static int io_import_umem(struct io_zcrx_ifq *ifq, if (ret) return ret; + mem->account_pages = io_count_account_pages(pages, nr_pages); + ret = io_account_mem(ifq->ctx, mem->account_pages); + if (ret < 0) { + mem->account_pages = 0; + return ret; + } + mem->pages = pages; mem->nr_folios = nr_pages; mem->size = area_reg->len; @@ -357,6 +381,9 @@ static void io_zcrx_free_area(struct io_zcrx_area *area) io_zcrx_unmap_area(area->ifq, area); io_release_area_mem(&area->mem); + if (area->mem.account_pages) + io_unaccount_mem(area->ifq->ctx, area->mem.account_pages); + kvfree(area->freelist); kvfree(area->nia.niovs); kvfree(area->user_refs); diff --git a/io_uring/zcrx.h b/io_uring/zcrx.h index 89015b923911..109c4ca36434 100644 --- a/io_uring/zcrx.h +++ b/io_uring/zcrx.h @@ -15,6 +15,7 @@ struct io_zcrx_mem { struct page **pages; unsigned long nr_folios; struct sg_table page_sg_table; + unsigned long account_pages; struct dma_buf_attachment *attach; struct dma_buf *dmabuf;

1 week, 1 day

3
2
0 0

[REGRESSION] stable-rc/linux-6.1.y: (build) call to undeclared function 'BIT_U32'; ISO C99 and later do not su...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- call to undeclared function 'BIT_U32'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] in drivers/net/can/ti_hecc.o (drivers/net/can/ti_hecc.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:8fd2dd605b4f4e3fdfb2bb48ed2965f305259b0d - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: de81846a25749c1fa21ba68cf4938d4309cfbcef Log excerpt: ===================================================== drivers/net/can/ti_hecc.c:387:14: error: call to undeclared function 'BIT_U32'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 387 | mbx_mask = ~BIT_U32(HECC_RX_LAST_MBOX); | ^ 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:68a32682233e484a3f9ea0aa #kernelci issue maestro:8fd2dd605b4f4e3fdfb2bb48ed2965f305259b0d Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror