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

FAILED: patch "[PATCH] Bluetooth: rfcomm: fix modem control handling" 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 91d35ec9b3956d6b3cf789c1593467e58855b03a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110250-establish-sanction-a45f@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 91d35ec9b3956d6b3cf789c1593467e58855b03a Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 23 Oct 2025 14:05:30 +0200 Subject: [PATCH] Bluetooth: rfcomm: fix modem control handling The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS). This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS. Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c index 376ce6de84be..b783526ab588 100644 --- a/net/bluetooth/rfcomm/tty.c +++ b/net/bluetooth/rfcomm/tty.c @@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig) tty_port_tty_hangup(&dev->port, true); dev->modem_status = - ((v24_sig & RFCOMM_V24_RTC) ? (TIOCM_DSR | TIOCM_DTR) : 0) | - ((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : 0) | + ((v24_sig & RFCOMM_V24_RTC) ? TIOCM_DSR : 0) | + ((v24_sig & RFCOMM_V24_RTR) ? TIOCM_CTS : 0) | ((v24_sig & RFCOMM_V24_IC) ? TIOCM_RI : 0) | ((v24_sig & RFCOMM_V24_DV) ? TIOCM_CD : 0); } @@ -1055,10 +1055,14 @@ static void rfcomm_tty_hangup(struct tty_struct *tty) static int rfcomm_tty_tiocmget(struct tty_struct *tty) { struct rfcomm_dev *dev = tty->driver_data; + struct rfcomm_dlc *dlc = dev->dlc; + u8 v24_sig; BT_DBG("tty %p dev %p", tty, dev); - return dev->modem_status; + rfcomm_dlc_get_modem_status(dlc, &v24_sig); + + return (v24_sig & (TIOCM_DTR | TIOCM_RTS)) | dev->modem_status; } static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigned int clear) @@ -1071,23 +1075,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigne rfcomm_dlc_get_modem_status(dlc, &v24_sig); - if (set & TIOCM_DSR || set & TIOCM_DTR) + if (set & TIOCM_DTR) v24_sig |= RFCOMM_V24_RTC; - if (set & TIOCM_RTS || set & TIOCM_CTS) + if (set & TIOCM_RTS) v24_sig |= RFCOMM_V24_RTR; - if (set & TIOCM_RI) - v24_sig |= RFCOMM_V24_IC; - if (set & TIOCM_CD) - v24_sig |= RFCOMM_V24_DV; - if (clear & TIOCM_DSR || clear & TIOCM_DTR) + if (clear & TIOCM_DTR) v24_sig &= ~RFCOMM_V24_RTC; - if (clear & TIOCM_RTS || clear & TIOCM_CTS) + if (clear & TIOCM_RTS) v24_sig &= ~RFCOMM_V24_RTR; - if (clear & TIOCM_RI) - v24_sig &= ~RFCOMM_V24_IC; - if (clear & TIOCM_CD) - v24_sig &= ~RFCOMM_V24_DV; rfcomm_dlc_set_modem_status(dlc, v24_sig);

2 days, 18 hours

1
0
0 0

FAILED: patch "[PATCH] Bluetooth: rfcomm: fix modem control handling" 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 91d35ec9b3956d6b3cf789c1593467e58855b03a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110248-creative-police-9150@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 91d35ec9b3956d6b3cf789c1593467e58855b03a Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 23 Oct 2025 14:05:30 +0200 Subject: [PATCH] Bluetooth: rfcomm: fix modem control handling The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS). This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS. Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c index 376ce6de84be..b783526ab588 100644 --- a/net/bluetooth/rfcomm/tty.c +++ b/net/bluetooth/rfcomm/tty.c @@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig) tty_port_tty_hangup(&dev->port, true); dev->modem_status = - ((v24_sig & RFCOMM_V24_RTC) ? (TIOCM_DSR | TIOCM_DTR) : 0) | - ((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : 0) | + ((v24_sig & RFCOMM_V24_RTC) ? TIOCM_DSR : 0) | + ((v24_sig & RFCOMM_V24_RTR) ? TIOCM_CTS : 0) | ((v24_sig & RFCOMM_V24_IC) ? TIOCM_RI : 0) | ((v24_sig & RFCOMM_V24_DV) ? TIOCM_CD : 0); } @@ -1055,10 +1055,14 @@ static void rfcomm_tty_hangup(struct tty_struct *tty) static int rfcomm_tty_tiocmget(struct tty_struct *tty) { struct rfcomm_dev *dev = tty->driver_data; + struct rfcomm_dlc *dlc = dev->dlc; + u8 v24_sig; BT_DBG("tty %p dev %p", tty, dev); - return dev->modem_status; + rfcomm_dlc_get_modem_status(dlc, &v24_sig); + + return (v24_sig & (TIOCM_DTR | TIOCM_RTS)) | dev->modem_status; } static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigned int clear) @@ -1071,23 +1075,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigne rfcomm_dlc_get_modem_status(dlc, &v24_sig); - if (set & TIOCM_DSR || set & TIOCM_DTR) + if (set & TIOCM_DTR) v24_sig |= RFCOMM_V24_RTC; - if (set & TIOCM_RTS || set & TIOCM_CTS) + if (set & TIOCM_RTS) v24_sig |= RFCOMM_V24_RTR; - if (set & TIOCM_RI) - v24_sig |= RFCOMM_V24_IC; - if (set & TIOCM_CD) - v24_sig |= RFCOMM_V24_DV; - if (clear & TIOCM_DSR || clear & TIOCM_DTR) + if (clear & TIOCM_DTR) v24_sig &= ~RFCOMM_V24_RTC; - if (clear & TIOCM_RTS || clear & TIOCM_CTS) + if (clear & TIOCM_RTS) v24_sig &= ~RFCOMM_V24_RTR; - if (clear & TIOCM_RI) - v24_sig &= ~RFCOMM_V24_IC; - if (clear & TIOCM_CD) - v24_sig &= ~RFCOMM_V24_DV; rfcomm_dlc_set_modem_status(dlc, v24_sig);

2 days, 18 hours

1
0
0 0

FAILED: patch "[PATCH] Bluetooth: rfcomm: fix modem control handling" 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 91d35ec9b3956d6b3cf789c1593467e58855b03a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110245-shore-stove-8c99@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 91d35ec9b3956d6b3cf789c1593467e58855b03a Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 23 Oct 2025 14:05:30 +0200 Subject: [PATCH] Bluetooth: rfcomm: fix modem control handling The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS). This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS. Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c index 376ce6de84be..b783526ab588 100644 --- a/net/bluetooth/rfcomm/tty.c +++ b/net/bluetooth/rfcomm/tty.c @@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig) tty_port_tty_hangup(&dev->port, true); dev->modem_status = - ((v24_sig & RFCOMM_V24_RTC) ? (TIOCM_DSR | TIOCM_DTR) : 0) | - ((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : 0) | + ((v24_sig & RFCOMM_V24_RTC) ? TIOCM_DSR : 0) | + ((v24_sig & RFCOMM_V24_RTR) ? TIOCM_CTS : 0) | ((v24_sig & RFCOMM_V24_IC) ? TIOCM_RI : 0) | ((v24_sig & RFCOMM_V24_DV) ? TIOCM_CD : 0); } @@ -1055,10 +1055,14 @@ static void rfcomm_tty_hangup(struct tty_struct *tty) static int rfcomm_tty_tiocmget(struct tty_struct *tty) { struct rfcomm_dev *dev = tty->driver_data; + struct rfcomm_dlc *dlc = dev->dlc; + u8 v24_sig; BT_DBG("tty %p dev %p", tty, dev); - return dev->modem_status; + rfcomm_dlc_get_modem_status(dlc, &v24_sig); + + return (v24_sig & (TIOCM_DTR | TIOCM_RTS)) | dev->modem_status; } static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigned int clear) @@ -1071,23 +1075,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigne rfcomm_dlc_get_modem_status(dlc, &v24_sig); - if (set & TIOCM_DSR || set & TIOCM_DTR) + if (set & TIOCM_DTR) v24_sig |= RFCOMM_V24_RTC; - if (set & TIOCM_RTS || set & TIOCM_CTS) + if (set & TIOCM_RTS) v24_sig |= RFCOMM_V24_RTR; - if (set & TIOCM_RI) - v24_sig |= RFCOMM_V24_IC; - if (set & TIOCM_CD) - v24_sig |= RFCOMM_V24_DV; - if (clear & TIOCM_DSR || clear & TIOCM_DTR) + if (clear & TIOCM_DTR) v24_sig &= ~RFCOMM_V24_RTC; - if (clear & TIOCM_RTS || clear & TIOCM_CTS) + if (clear & TIOCM_RTS) v24_sig &= ~RFCOMM_V24_RTR; - if (clear & TIOCM_RI) - v24_sig &= ~RFCOMM_V24_IC; - if (clear & TIOCM_CD) - v24_sig &= ~RFCOMM_V24_DV; rfcomm_dlc_set_modem_status(dlc, v24_sig);

2 days, 18 hours

1
0
0 0

FAILED: patch "[PATCH] Bluetooth: rfcomm: fix modem control handling" 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 91d35ec9b3956d6b3cf789c1593467e58855b03a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025110242-armory-enlisted-e259@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 91d35ec9b3956d6b3cf789c1593467e58855b03a Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 23 Oct 2025 14:05:30 +0200 Subject: [PATCH] Bluetooth: rfcomm: fix modem control handling The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS). This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS. Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c index 376ce6de84be..b783526ab588 100644 --- a/net/bluetooth/rfcomm/tty.c +++ b/net/bluetooth/rfcomm/tty.c @@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig) tty_port_tty_hangup(&dev->port, true); dev->modem_status = - ((v24_sig & RFCOMM_V24_RTC) ? (TIOCM_DSR | TIOCM_DTR) : 0) | - ((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : 0) | + ((v24_sig & RFCOMM_V24_RTC) ? TIOCM_DSR : 0) | + ((v24_sig & RFCOMM_V24_RTR) ? TIOCM_CTS : 0) | ((v24_sig & RFCOMM_V24_IC) ? TIOCM_RI : 0) | ((v24_sig & RFCOMM_V24_DV) ? TIOCM_CD : 0); } @@ -1055,10 +1055,14 @@ static void rfcomm_tty_hangup(struct tty_struct *tty) static int rfcomm_tty_tiocmget(struct tty_struct *tty) { struct rfcomm_dev *dev = tty->driver_data; + struct rfcomm_dlc *dlc = dev->dlc; + u8 v24_sig; BT_DBG("tty %p dev %p", tty, dev); - return dev->modem_status; + rfcomm_dlc_get_modem_status(dlc, &v24_sig); + + return (v24_sig & (TIOCM_DTR | TIOCM_RTS)) | dev->modem_status; } static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigned int clear) @@ -1071,23 +1075,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigne rfcomm_dlc_get_modem_status(dlc, &v24_sig); - if (set & TIOCM_DSR || set & TIOCM_DTR) + if (set & TIOCM_DTR) v24_sig |= RFCOMM_V24_RTC; - if (set & TIOCM_RTS || set & TIOCM_CTS) + if (set & TIOCM_RTS) v24_sig |= RFCOMM_V24_RTR; - if (set & TIOCM_RI) - v24_sig |= RFCOMM_V24_IC; - if (set & TIOCM_CD) - v24_sig |= RFCOMM_V24_DV; - if (clear & TIOCM_DSR || clear & TIOCM_DTR) + if (clear & TIOCM_DTR) v24_sig &= ~RFCOMM_V24_RTC; - if (clear & TIOCM_RTS || clear & TIOCM_CTS) + if (clear & TIOCM_RTS) v24_sig &= ~RFCOMM_V24_RTR; - if (clear & TIOCM_RI) - v24_sig &= ~RFCOMM_V24_IC; - if (clear & TIOCM_CD) - v24_sig &= ~RFCOMM_V24_DV; rfcomm_dlc_set_modem_status(dlc, v24_sig);

2 days, 18 hours

1
0
0 0

WTF: patch "[PATCH] video: fb: Fix typo in comment in fb.h" was seriously submitted to be applied to the 6.17-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 6.17-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 18cd0a9c7aaf880502e4aff3ea30022f97d6c103 Mon Sep 17 00:00:00 2001 From: PIYUSH CHOUDHARY <mercmerc961(a)gmail.com> Date: Mon, 20 Oct 2025 00:05:08 +0530 Subject: [PATCH] video: fb: Fix typo in comment in fb.h Fix typo: "verical" -> "vertical" in macro description Signed-off-by: PIYUSH CHOUDHARY <mercmerc961(a)gmail.com> Signed-off-by: Helge Deller <deller(a)gmx.de> Cc: stable(a)vger.kernel.org diff --git a/include/uapi/linux/fb.h b/include/uapi/linux/fb.h index cde8f173f566..22acaaec7b1c 100644 --- a/include/uapi/linux/fb.h +++ b/include/uapi/linux/fb.h @@ -319,7 +319,7 @@ enum { #define FB_VBLANK_HAVE_VCOUNT 0x020 /* the vcount field is valid */ #define FB_VBLANK_HAVE_HCOUNT 0x040 /* the hcount field is valid */ #define FB_VBLANK_VSYNCING 0x080 /* currently in a vsync */ -#define FB_VBLANK_HAVE_VSYNC 0x100 /* verical syncs can be detected */ +#define FB_VBLANK_HAVE_VSYNC 0x100 /* vertical syncs can be detected */ struct fb_vblank { __u32 flags; /* FB_VBLANK flags */

2 days, 18 hours

1
0
0 0

[PATCH 6.6 00/32] 6.6.116-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.6.116 release. There are 32 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 Sun, 02 Nov 2025 14:00:34 +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.6.116-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.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.6.116-rc1 William Breathitt Gray <wbg(a)kernel.org> gpio: idio-16: Define fixed direction of the GPIO lines Ioana Ciornei <ioana.ciornei(a)nxp.com> gpio: regmap: add the .fixed_direction_output configuration parameter Mathieu Dubois-Briand <mathieu.dubois-briand(a)bootlin.com> gpio: regmap: Allow to allocate regmap-irq device Vincent Mailhol <mailhol.vincent(a)wanadoo.fr> bits: introduce fixed-type GENMASK_U*() Vincent Mailhol <mailhol.vincent(a)wanadoo.fr> bits: add comments and newlines to #if, #else and #endif directives Mathias Nyman <mathias.nyman(a)linux.intel.com> xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event Mathias Nyman <mathias.nyman(a)linux.intel.com> xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive. Mathias Nyman <mathias.nyman(a)linux.intel.com> xhci: dbc: Improve performance by removing delay in transfer event polling. Uday M Bhat <uday.m.bhat(a)intel.com> xhci: dbc: Allow users to modify DbC poll interval via sysfs Mathias Nyman <mathias.nyman(a)linux.intel.com> xhci: dbc: poll at different rate depending on data transfer activity Hugo Villeneuve <hvilleneuve(a)dimonoff.com> serial: sc16is7xx: remove useless enable of enhanced features Hugo Villeneuve <hvilleneuve(a)dimonoff.com> serial: sc16is7xx: refactor EFR lock Hugo Villeneuve <hvilleneuve(a)dimonoff.com> serial: sc16is7xx: reorder code to remove prototype declarations Hugo Villeneuve <hvilleneuve(a)dimonoff.com> serial: sc16is7xx: remove unused to_sc16is7xx_port macro Matthieu Baerts (NGI0) <matttbe(a)kernel.org> selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported Geliang Tang <tanggeliang(a)kylinos.cn> selftests: mptcp: disable add_addr retrans in endpoint_tests Matthieu Baerts (NGI0) <matttbe(a)kernel.org> mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR Menglong Dong <menglong8.dong(a)gmail.com> arch: Add the macro COMPILE_OFFSETS to all the asm-offsets.c Filipe Manana <fdmanana(a)suse.com> btrfs: use smp_mb__after_atomic() when forcing COW in create_pending_snapshot() Filipe Manana <fdmanana(a)suse.com> btrfs: use level argument in log tree walk callback replay_one_buffer() Filipe Manana <fdmanana(a)suse.com> btrfs: always drop log root tree reference in btrfs_replay_log() Thorsten Blum <thorsten.blum(a)linux.dev> btrfs: scrub: replace max_t()/min_t() with clamp() in scrub_throttle_dev_io() Naohiro Aota <naohiro.aota(a)wdc.com> btrfs: zoned: refine extent allocator hint selection Johannes Thumshirn <johannes.thumshirn(a)wdc.com> btrfs: zoned: return error from btrfs_zone_finish_endio() Avadhut Naik <avadhut.naik(a)amd.com> EDAC/mc_sysfs: Increase legacy channel support to 16 David Kaplan <david.kaplan(a)amd.com> x86/bugs: Fix reporting of LFENCE retpoline David Kaplan <david.kaplan(a)amd.com> x86/bugs: Report correct retbleed mitigation status Josh Poimboeuf <jpoimboe(a)kernel.org> perf: Skip user unwind if the task is a kernel thread Josh Poimboeuf <jpoimboe(a)kernel.org> perf: Have get_perf_callchain() return NULL if crosstask and user are set Steven Rostedt <rostedt(a)goodmis.org> perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of current->mm == NULL Richard Guy Briggs <rgb(a)redhat.com> audit: record fanotify event regardless of presence of rules Xiang Mei <xmei5(a)asu.edu> net/sched: sch_qfq: Fix null-deref in agg_dequeue ------------- Diffstat: .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 10 ++ Makefile | 4 +- arch/alpha/kernel/asm-offsets.c | 1 + arch/arc/kernel/asm-offsets.c | 1 + arch/arm/kernel/asm-offsets.c | 2 + arch/arm64/kernel/asm-offsets.c | 1 + arch/csky/kernel/asm-offsets.c | 1 + arch/hexagon/kernel/asm-offsets.c | 1 + arch/loongarch/kernel/asm-offsets.c | 2 + arch/m68k/kernel/asm-offsets.c | 1 + arch/microblaze/kernel/asm-offsets.c | 1 + arch/mips/kernel/asm-offsets.c | 2 + arch/nios2/kernel/asm-offsets.c | 1 + arch/openrisc/kernel/asm-offsets.c | 1 + arch/parisc/kernel/asm-offsets.c | 1 + arch/powerpc/kernel/asm-offsets.c | 1 + arch/riscv/kernel/asm-offsets.c | 1 + arch/s390/kernel/asm-offsets.c | 1 + arch/sh/kernel/asm-offsets.c | 1 + arch/sparc/kernel/asm-offsets.c | 1 + arch/um/kernel/asm-offsets.c | 2 + arch/x86/kernel/cpu/bugs.c | 9 +- arch/xtensa/kernel/asm-offsets.c | 1 + drivers/edac/edac_mc_sysfs.c | 24 +++ drivers/gpio/gpio-idio-16.c | 5 + drivers/gpio/gpio-regmap.c | 53 +++++- drivers/tty/serial/sc16is7xx.c | 185 ++++++++++----------- drivers/usb/host/xhci-dbgcap.c | 70 +++++++- drivers/usb/host/xhci-dbgcap.h | 7 +- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 6 +- fs/btrfs/inode.c | 7 +- fs/btrfs/scrub.c | 3 +- fs/btrfs/transaction.c | 2 +- fs/btrfs/tree-log.c | 9 +- fs/btrfs/zoned.c | 8 +- fs/btrfs/zoned.h | 9 +- include/linux/audit.h | 2 +- include/linux/bitops.h | 1 - include/linux/bits.h | 38 ++++- include/linux/gpio/regmap.h | 16 ++ include/net/pkt_sched.h | 25 ++- kernel/events/callchain.c | 16 +- kernel/events/core.c | 7 +- net/mptcp/pm_netlink.c | 6 + net/sched/sch_api.c | 10 -- net/sched/sch_hfsc.c | 16 -- net/sched/sch_qfq.c | 2 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 3 +- 49 files changed, 405 insertions(+), 174 deletions(-)

3 days, 11 hours

9
40
0 0

[PATCH 00/22] mm/damon/tests: fix memory bugs in kunit tests

by SeongJae Park

DAMON kunit tests were initially written assuming those will be run on environments that are well controlled and therefore tolerant to transient test failures and bugs in the test code itself. The user-mode linux based manual run of the tests is one example of such an environment. And the test code was written for adding more test coverage as fast as possible, over making those safe and reliable. As a result, the tests resulted in having a number of bugs including real memory leaks, theoretical unhandled memory allocation failures, and unused memory allocations. The allocation failures that are not handled well are unlikely in the real world, since those allocations are too small to fail. But in theory, it can happen and cause inappropriate memory access. It is arguable if bugs in test code can really harm users. But, anyway bugs are bugs that need to be fixed. Fix the bugs one by one. Also Cc stable@ for the fixes of memory leak and unhandled memory allocation failures. The unused memory allocations are only a matter of memory efficiency, so not Cc-ing stable@. The first patch fixes memory leaks in the test code for the DAMON core layer. Following fifteen, three, and one patches respectively fix unhandled memory allocation failures in the test code for DAMON core layer, virtual address space DAMON operation set, and DAMON sysfs interface, one by one per test function. Final two patches remove memory allocations that are correctly deallocated at the end, but not really being used by any code. SeongJae Park (22): mm/damon/tests/core-kunit: fix memory leak in damon_test_set_filters_default_reject() mm/damon/tests/core-kunit: handle allocation failures in damon_test_regions() mm/damon/tests/core-kunit: handle memory failure from damon_test_target() mm/damon/tests/core-kunit: handle memory alloc failure from damon_test_aggregate() mm/damon/tests/core-kunit: handle alloc failures on damon_test_split_at() mm/damon/tests/core-kunit: handle alloc failures on damon_test_merge_two() mm/damon/tests/core-kunit: handle alloc failures on dasmon_test_merge_regions_of() mm/damon/tests/core-kunit: handle alloc failures on damon_test_split_regions_of() mm/damon/tests/core-kunit: handle alloc failures in damon_test_ops_registration() mm/damon/tests/core-kunit: handle alloc failures in damon_test_set_regions() mm/damon/tests/core-kunit: handle alloc failures in damon_test_update_monitoring_result() mm/damon/tests/core-kunit: handle alloc failure on damon_test_set_attrs() mm/damon/tests/core-kunit: handle alloc failres in damon_test_new_filter() mm/damon/tests/core-kunit: handle alloc failure on damos_test_commit_filter() mm/damon/tests/core-kunit: handle alloc failures on damos_test_filter_out() mm/damon/tests/core-kunit: handle alloc failures on damon_test_set_filters_default_reject() mm/damon/tests/vaddr-kunit: handle alloc failures on damon_do_test_apply_three_regions() mm/damon/tests/vaddr-kunit: handle alloc failures in damon_test_split_evenly_fail() mm/damon/tests/vaddr-kunit: handle alloc failures on damon_test_split_evenly_succ() mm/damon/tests/sysfs-kunit: handle alloc failures on damon_sysfs_test_add_targets() mm/damon/tests/core-kunit: remove unnecessary damon_ctx variable on damon_test_split_at() mm/damon/tests/core-kunit: remove unused ctx in damon_test_split_regions_of() mm/damon/tests/core-kunit.h | 125 ++++++++++++++++++++++++++++++++--- mm/damon/tests/sysfs-kunit.h | 25 +++++++ mm/damon/tests/vaddr-kunit.h | 26 +++++++- 3 files changed, 163 insertions(+), 13 deletions(-) base-commit: 75f0c76bb8c01fdea838a601dc3326b11177c0d8 -- 2.47.3

3 days, 13 hours

1
20
0 0

Original T shirts!

by Spencer

3 days, 13 hours

1
0
0 0

20% Off IAA MOBILITY 2025 List!

by Garnet Conwell

Hi, Great news! Our verified IAA MOBILITY 2025 database is now ready — featuring 501,846 attendees and 750 exhibitors from this year’s event. You’ll get complete and verified contact details, including: Contact name, Job Title, Business Name, Physical Address, Phone Numbers, Official Email address and many more. Delivered Within 48 Hours Halloween Special: Enjoy 20% off when you order during our limited-time offer! Interested? Just reply “Send me the cost”, and I’ll share the pricing details right away. Warm regards, Garnet Conwell Sr. Marketing Manager P.S. If you’d prefer not to receive future updates, simply reply “Unfollow.”

3 days, 22 hours

1
0
0 0

[PATCH] tools/testing/nvdimm: Stop read past end of global handle array

by Alison Schofield

KASAN reports a global-out-of-bounds access when running these nfit tests: clear.sh, pmem-errors, pfn-meta-errors.sh, btt-errors.sh, daxdev-errors.sh, and inject-error.sh. [] BUG: KASAN: global-out-of-bounds in nfit_test_ctl+0x769f/0x7840 [nfit_test] [] Read of size 4 at addr ffffffffc03ea01c by task ndctl/1215 [] The buggy address belongs to the variable: [] handle+0x1c/0x1df4 [nfit_test] The nfit_test mock platform defines a static table of 7 NFIT DIMM handles, but nfit_test.0 builds 8 mock DIMMs total (5 DCR + 3 PM). When the final DIMM (id == 7) is selected, this code: spa->devices[0].nfit_device_handle = handle[nvdimm->id]; indexes past the end of the 7-entry table, triggering KASAN. Fix this by adding an eighth entry to the handle[] table and a defensive bounds check so the test fails cleanly instead of dereferencing out-of-bounds memory. To generate a unique handle, the new entry sets the 'imc' field rather than the 'chan' field. This matches the pattern of earlier entries and avoids introducing a non-zero 'chan' which is never used in the table. Computing the new handle shows no collision. Notes from spelunkering for a Fixes Tag: Commit 209851649dc4 ("acpi: nfit: Add support for hot-add") increased the mock DIMMs to eight yet kept the handle[] array at seven. Commit 10246dc84dfc ("acpi nfit: nfit_test supports translate SPA") began using the last mock DIMM, triggering the KASAN. Commit af31b04b67f4 ("tools/testing/nvdimm: Fix the array size for dimm devices.") addressed a related KASAN warning but not the actual handle array length. Fixes: 209851649dc4 ("acpi: nfit: Add support for hot-add") Cc: <stable(a)vger.kernel.org> Signed-off-by: Alison Schofield <alison.schofield(a)intel.com> --- tools/testing/nvdimm/test/nfit.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c index cfd4378e2129..cdbf9e8ee80a 100644 --- a/tools/testing/nvdimm/test/nfit.c +++ b/tools/testing/nvdimm/test/nfit.c @@ -129,6 +129,7 @@ static u32 handle[] = { [4] = NFIT_DIMM_HANDLE(0, 1, 0, 0, 0), [5] = NFIT_DIMM_HANDLE(1, 0, 0, 0, 0), [6] = NFIT_DIMM_HANDLE(1, 0, 0, 0, 1), + [7] = NFIT_DIMM_HANDLE(1, 0, 1, 0, 1), }; static unsigned long dimm_fail_cmd_flags[ARRAY_SIZE(handle)]; @@ -688,6 +689,13 @@ static int nfit_test_search_spa(struct nvdimm_bus *bus, nd_mapping = &nd_region->mapping[nd_region->ndr_mappings - 1]; nvdimm = nd_mapping->nvdimm; + if (WARN_ON_ONCE(nvdimm->id >= ARRAY_SIZE(handle))) { + dev_err(&bus->dev, + "invalid nvdimm->id %u >= handle array size %zu\n", + nvdimm->id, ARRAY_SIZE(handle)); + return -EINVAL; + } + spa->devices[0].nfit_device_handle = handle[nvdimm->id]; spa->num_nvdimms = 1; spa->devices[0].dpa = dpa; base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada -- 2.37.3

4 days, 8 hours

3
3
0 0

[PATCH] arm64: dts: rockchip: include rk3399-base instead of rk3399 in rk3399-op1

by Quentin Schulz

From: Quentin Schulz <quentin.schulz(a)cherry.de> In commit 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399 OPPs to dtsi files for SoC variants"), everything shared between variants of RK3399 was put into rk3399-base.dtsi and the rest in variant-specific DTSI, such as rk3399-t, rk3399-op1, rk3399, etc. Therefore, the variant-specific DTSI should include rk3399-base.dtsi and not another variant's DTSI. rk3399-op1 wrongly includes rk3399 (a variant) DTSI instead of rk3399-base DTSI, let's fix this oversight by including the intended DTSI. Fortunately, this had no impact on the resulting DTB since all nodes were named the same and all node properties were overridden in rk3399-op1.dtsi. This was checked by doing a checksum of rk3399-op1 DTBs before and after this commit. No intended change in behavior. Fixes: 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399 OPPs to dtsi files for SoC variants") Cc: stable(a)vger.kernel.org Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi index c4f4f1ff6117b..9da6fd82e46b2 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-op1.dtsi @@ -3,7 +3,7 @@ * Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd */ -#include "rk3399.dtsi" +#include "rk3399-base.dtsi" / { cluster0_opp: opp-table-0 { --- base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6 change-id: 20251029-rk3399-op1-include-b311b4e16909 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

4 days, 9 hours

3
2
0 0

[PATCH v2] arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2

by Diederik de Haas

Page 13 of the PineTab2 v2 schematic dd 20230417 shows VCCIO4's power source is VCCIO_WL. Page 19 shows that VCCIO_WL is connected to VCCA1V8_PMU, so fix the PineTab2 dtsi to reflect that. Fixes: 1b7e19448f8f ("arm64: dts: rockchip: Add devicetree for Pine64 PineTab2") Cc: stable(a)vger.kernel.org Reviewed-by: Dragan Simic <dsimic(a)manjaro.org> Signed-off-by: Diederik de Haas <diederik(a)cknow-tech.com> --- Changes since v1: - Added Fixes tag (Dragan) - Added R-b tag arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi index d0e38412d56a..08bf40de17ea 100644 --- a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi @@ -789,7 +789,7 @@ &pmu_io_domains { vccio1-supply = <&vccio_acodec>; vccio2-supply = <&vcc_1v8>; vccio3-supply = <&vccio_sd>; - vccio4-supply = <&vcc_1v8>; + vccio4-supply = <&vcca1v8_pmu>; vccio5-supply = <&vcc_1v8>; vccio6-supply = <&vcc1v8_dvp>; vccio7-supply = <&vcc_3v3>; -- 2.51.0

4 days, 9 hours

2
1
0 0

+ mm-secretmem-fix-use-after-free-race-in-fault-handler.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/secretmem: fix use-after-free race in fault handler has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-secretmem-fix-use-after-free-race-in-fault-handler.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lance Yang <lance.yang(a)linux.dev> Subject: mm/secretmem: fix use-after-free race in fault handler Date: Fri, 31 Oct 2025 20:09:55 +0800 When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed. Link: https://lkml.kernel.org/r/20251031120955.92116-1-lance.yang@linux.dev Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Lance Yang <lance.yang(a)linux.dev> Reported-by: Google Big Sleep <big-sleep-vuln-reports(a)google.com> Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWK… Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/secretmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/secretmem.c~mm-secretmem-fix-use-after-free-race-in-fault-handler +++ a/mm/secretmem.c @@ -82,13 +82,13 @@ retry: __folio_mark_uptodate(folio); err = filemap_add_folio(mapping, folio, offset, gfp); if (unlikely(err)) { - folio_put(folio); /* * If a split of large page was required, it * already happened when we marked the page invalid * which guarantees that this call won't fail */ set_direct_map_default_noflush(folio_page(folio, 0)); + folio_put(folio); if (err == -EEXIST) goto retry; _ Patches currently in -mm which might be from lance.yang(a)linux.dev are mm-secretmem-fix-use-after-free-race-in-fault-handler.patch mm-khugepaged-guard-is_zero_pfn-calls-with-pte_present.patch

4 days, 10 hours

1
0
0 0

[PATCH 0/2] fuse: Fix missing fuse_copy_finish in dev_uring.c

by Bernd Schubert

Both argument copies in dev_uring.c miss fuse_copy_finish. Signed-off-by: Bernd Schubert <bschubert(a)ddn.com> --- Bernd Schubert (1): fuse: Fix whitespace for fuse_uring_args_to_ring() comment Cheng Ding (1): fuse: missing copy_finish in fuse-over-io-uring argument copies fs/fuse/dev.c | 2 +- fs/fuse/dev_uring.c | 18 ++++++++++++------ fs/fuse/fuse_dev_i.h | 1 + 3 files changed, 14 insertions(+), 7 deletions(-) --- base-commit: 6548d364a3e850326831799d7e3ea2d7bb97ba08 change-id: 20251021-io-uring-fixes-copy-finish-07ae602e2ab1 Best regards, -- Bernd Schubert <bschubert(a)ddn.com>

4 days, 10 hours

2
2
0 0

[PATCH] mount: fix duplicate mounts using the new mount API

by GuangFei Luo

When using the new mount API, invoking the same mount command multiple times such as: mount /dev/mapper/mydevice /mnt/mydisk2 results in multiple identical mount entries being created: /dev/mapper/mydevice on /mnt/mydisk2 type ext4 (rw,relatime) /dev/mapper/mydevice on /mnt/mydisk2 type ext4 (rw,relatime) /dev/mapper/mydevice on /mnt/mydisk2 type ext4 (rw,relatime) ... Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") Signed-off-by: GuangFei Luo <luogf2025(a)163.com> Cc: <stable(a)vger.kernel.org> # 5.2+ --- fs/namespace.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/namespace.c b/fs/namespace.c index d82910f33dc4..9436471955ce 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -4427,6 +4427,7 @@ SYSCALL_DEFINE5(move_mount, { struct path to_path __free(path_put) = {}; struct path from_path __free(path_put) = {}; + struct path path __free(path_put) = {}; struct filename *to_name __free(putname) = NULL; struct filename *from_name __free(putname) = NULL; unsigned int lflags, uflags; @@ -4472,6 +4473,14 @@ SYSCALL_DEFINE5(move_mount, return ret; } + ret = user_path_at(AT_FDCWD, to_pathname, LOOKUP_FOLLOW, &path); + if (ret) + return ret; + + /* Refuse the same filesystem on the same mount point */ + if (path.mnt->mnt_sb == to_path.mnt->mnt_sb && path_mounted(&path)) + return -EBUSY; + uflags = 0; if (flags & MOVE_MOUNT_F_EMPTY_PATH) uflags = AT_EMPTY_PATH; -- 2.43.0

4 days, 13 hours

4
5
0 0

[PATCH stable 5.10] sched/deadline: only set free_cpus for online runqueues

by Florian Fainelli

From: Doug Berger <opendmb(a)gmail.com> [ Upstream commit 382748c05e58a9f1935f5a653c352422375566ea ] Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus to reflect rd->online") introduced the cpudl_set/clear_freecpu functions to allow the cpu_dl::free_cpus mask to be manipulated by the deadline scheduler class rq_on/offline callbacks so the mask would also reflect this state. Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask from cpudl_find()") removed the check of the cpu_active_mask to save some processing on the premise that the cpudl::free_cpus mask already reflected the runqueue online state. Unfortunately, there are cases where it is possible for the cpudl_clear function to set the free_cpus bit for a CPU when the deadline runqueue is offline. When this occurs while a CPU is connected to the default root domain the flag may retain the bad state after the CPU has been unplugged. Later, a different CPU that is transitioning through the default root domain may push a deadline task to the powered down CPU when cpudl_find sees its free_cpus bit is set. If this happens the task will not have the opportunity to run. One example is outlined here: https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com Another occurs when the last deadline task is migrated from a CPU that has an offlined runqueue. The dequeue_task member of the deadline scheduler class will eventually call cpudl_clear and set the free_cpus bit for the CPU. This commit modifies the cpudl_clear function to be aware of the online state of the deadline runqueue so that the free_cpus mask can be updated appropriately. It is no longer necessary to manage the mask outside of the cpudl_set/clear functions so the cpudl_set/clear_freecpu functions are removed. In addition, since the free_cpus mask is now only updated under the cpudl lock the code was changed to use the non-atomic __cpumask functions. Signed-off-by: Doug Berger <opendmb(a)gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Signed-off-by: Florian Fainelli <florian.fainelli(a)broadcom.com> --- kernel/sched/cpudeadline.c | 34 +++++++++------------------------- kernel/sched/cpudeadline.h | 4 +--- kernel/sched/deadline.c | 8 ++++---- 3 files changed, 14 insertions(+), 32 deletions(-) diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c index 8cb06c8c7eb1..fd28ba4e1a28 100644 --- a/kernel/sched/cpudeadline.c +++ b/kernel/sched/cpudeadline.c @@ -166,12 +166,13 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p, * cpudl_clear - remove a CPU from the cpudl max-heap * @cp: the cpudl max-heap context * @cpu: the target CPU + * @online: the online state of the deadline runqueue * * Notes: assumes cpu_rq(cpu)->lock is locked * * Returns: (void) */ -void cpudl_clear(struct cpudl *cp, int cpu) +void cpudl_clear(struct cpudl *cp, int cpu, bool online) { int old_idx, new_cpu; unsigned long flags; @@ -184,7 +185,7 @@ void cpudl_clear(struct cpudl *cp, int cpu) if (old_idx == IDX_INVALID) { /* * Nothing to remove if old_idx was invalid. - * This could happen if a rq_offline_dl is + * This could happen if rq_online_dl or rq_offline_dl is * called for a CPU without -dl tasks running. */ } else { @@ -195,9 +196,12 @@ void cpudl_clear(struct cpudl *cp, int cpu) cp->elements[new_cpu].idx = old_idx; cp->elements[cpu].idx = IDX_INVALID; cpudl_heapify(cp, old_idx); - - cpumask_set_cpu(cpu, cp->free_cpus); } + if (likely(online)) + __cpumask_set_cpu(cpu, cp->free_cpus); + else + __cpumask_clear_cpu(cpu, cp->free_cpus); + raw_spin_unlock_irqrestore(&cp->lock, flags); } @@ -228,7 +232,7 @@ void cpudl_set(struct cpudl *cp, int cpu, u64 dl) cp->elements[new_idx].cpu = cpu; cp->elements[cpu].idx = new_idx; cpudl_heapify_up(cp, new_idx); - cpumask_clear_cpu(cpu, cp->free_cpus); + __cpumask_clear_cpu(cpu, cp->free_cpus); } else { cp->elements[old_idx].dl = dl; cpudl_heapify(cp, old_idx); @@ -237,26 +241,6 @@ void cpudl_set(struct cpudl *cp, int cpu, u64 dl) raw_spin_unlock_irqrestore(&cp->lock, flags); } -/* - * cpudl_set_freecpu - Set the cpudl.free_cpus - * @cp: the cpudl max-heap context - * @cpu: rd attached CPU - */ -void cpudl_set_freecpu(struct cpudl *cp, int cpu) -{ - cpumask_set_cpu(cpu, cp->free_cpus); -} - -/* - * cpudl_clear_freecpu - Clear the cpudl.free_cpus - * @cp: the cpudl max-heap context - * @cpu: rd attached CPU - */ -void cpudl_clear_freecpu(struct cpudl *cp, int cpu) -{ - cpumask_clear_cpu(cpu, cp->free_cpus); -} - /* * cpudl_init - initialize the cpudl structure * @cp: the cpudl max-heap context diff --git a/kernel/sched/cpudeadline.h b/kernel/sched/cpudeadline.h index 0adeda93b5fb..ecff718d94ae 100644 --- a/kernel/sched/cpudeadline.h +++ b/kernel/sched/cpudeadline.h @@ -18,9 +18,7 @@ struct cpudl { #ifdef CONFIG_SMP int cpudl_find(struct cpudl *cp, struct task_struct *p, struct cpumask *later_mask); void cpudl_set(struct cpudl *cp, int cpu, u64 dl); -void cpudl_clear(struct cpudl *cp, int cpu); +void cpudl_clear(struct cpudl *cp, int cpu, bool online); int cpudl_init(struct cpudl *cp); -void cpudl_set_freecpu(struct cpudl *cp, int cpu); -void cpudl_clear_freecpu(struct cpudl *cp, int cpu); void cpudl_cleanup(struct cpudl *cp); #endif /* CONFIG_SMP */ diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 6548bd90c5c3..85e4ef476686 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1414,7 +1414,7 @@ static void dec_dl_deadline(struct dl_rq *dl_rq, u64 deadline) if (!dl_rq->dl_nr_running) { dl_rq->earliest_dl.curr = 0; dl_rq->earliest_dl.next = 0; - cpudl_clear(&rq->rd->cpudl, rq->cpu); + cpudl_clear(&rq->rd->cpudl, rq->cpu, rq->online); } else { struct rb_node *leftmost = dl_rq->root.rb_leftmost; struct sched_dl_entity *entry; @@ -2349,9 +2349,10 @@ static void rq_online_dl(struct rq *rq) if (rq->dl.overloaded) dl_set_overload(rq); - cpudl_set_freecpu(&rq->rd->cpudl, rq->cpu); if (rq->dl.dl_nr_running > 0) cpudl_set(&rq->rd->cpudl, rq->cpu, rq->dl.earliest_dl.curr); + else + cpudl_clear(&rq->rd->cpudl, rq->cpu, true); } /* Assumes rq->lock is held */ @@ -2360,8 +2361,7 @@ static void rq_offline_dl(struct rq *rq) if (rq->dl.overloaded) dl_clear_overload(rq); - cpudl_clear(&rq->rd->cpudl, rq->cpu); - cpudl_clear_freecpu(&rq->rd->cpudl, rq->cpu); + cpudl_clear(&rq->rd->cpudl, rq->cpu, false); } void __init init_sched_dl_class(void) -- 2.34.1

4 days, 14 hours

2
8
0 0

[PATCH v2 1/5] mm, swap: do not perform synchronous discard during allocation

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> Since commit 1b7e90020eb77 ("mm, swap: use percpu cluster as allocation fast path"), swap allocation is protected by a local lock, which means we can't do any sleeping calls during allocation. However, the discard routine is not taken well care of. When the swap allocator failed to find any usable cluster, it would look at the pending discard cluster and try to issue some blocking discards. It may not necessarily sleep, but the cond_resched at the bio layer indicates this is wrong when combined with a local lock. And the bio GFP flag used for discard bio is also wrong (not atomic). It's arguable whether this synchronous discard is helpful at all. In most cases, the async discard is good enough. And the swap allocator is doing very differently at organizing the clusters since the recent change, so it is very rare to see discard clusters piling up. So far, no issues have been observed or reported with typical SSD setups under months of high pressure. This issue was found during my code review. But by hacking the kernel a bit: adding a mdelay(500) in the async discard path, this issue will be observable with WARNING triggered by the wrong GFP and cond_resched in the bio layer for debug builds. So now let's apply a hotfix for this issue: remove the synchronous discard in the swap allocation path. And when order 0 is failing with all cluster list drained on all swap devices, try to do a discard following the swap device priority list. If any discards released some cluster, try the allocation again. This way, we can still avoid OOM due to swap failure if the hardware is very slow and memory pressure is extremely high. This may cause more fragmentation issues if the discarding hardware is really slow. Ideally, we want to discard pending clusters before continuing to iterate the fragment cluster lists. This can be implemented in a cleaner way if we clean up the device list iteration part first. Cc: stable(a)vger.kernel.org Fixes: 1b7e90020eb77 ("mm, swap: use percpu cluster as allocation fast path") Acked-by: Nhat Pham <nphamcs(a)gmail.com> Signed-off-by: Kairui Song <kasong(a)tencent.com> --- mm/swapfile.c | 40 +++++++++++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 7 deletions(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index cb2392ed8e0e..33e0bd905c55 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1101,13 +1101,6 @@ static unsigned long cluster_alloc_swap_entry(struct swap_info_struct *si, int o goto done; } - /* - * We don't have free cluster but have some clusters in discarding, - * do discard now and reclaim them. - */ - if ((si->flags & SWP_PAGE_DISCARD) && swap_do_scheduled_discard(si)) - goto new_cluster; - if (order) goto done; @@ -1394,6 +1387,33 @@ static bool swap_alloc_slow(swp_entry_t *entry, return false; } +/* + * Discard pending clusters in a synchronized way when under high pressure. + * Return: true if any cluster is discarded. + */ +static bool swap_sync_discard(void) +{ + bool ret = false; + int nid = numa_node_id(); + struct swap_info_struct *si, *next; + + spin_lock(&swap_avail_lock); + plist_for_each_entry_safe(si, next, &swap_avail_heads[nid], avail_lists[nid]) { + spin_unlock(&swap_avail_lock); + if (get_swap_device_info(si)) { + if (si->flags & SWP_PAGE_DISCARD) + ret = swap_do_scheduled_discard(si); + put_swap_device(si); + } + if (ret) + return true; + spin_lock(&swap_avail_lock); + } + spin_unlock(&swap_avail_lock); + + return false; +} + /** * folio_alloc_swap - allocate swap space for a folio * @folio: folio we want to move to swap @@ -1432,11 +1452,17 @@ int folio_alloc_swap(struct folio *folio, gfp_t gfp) } } +again: local_lock(&percpu_swap_cluster.lock); if (!swap_alloc_fast(&entry, order)) swap_alloc_slow(&entry, order); local_unlock(&percpu_swap_cluster.lock); + if (unlikely(!order && !entry.val)) { + if (swap_sync_discard()) + goto again; + } + /* Need to call this even if allocation failed, for MEMCG_SWAP_FAIL. */ if (mem_cgroup_try_charge_swap(folio, entry)) goto out_free; -- 2.51.0

4 days, 14 hours

2
1
0 0

[PATCH 0/3] PCI: meson: Fix the parsing of DBI region

by Manivannan Sadhasivam

Hi, This compile tested only series aims to fix the DBI parsing issue repored in [1]. The issue stems from the fact that the DT and binding describing 'dbi' region as 'elbi' from the start. Now, both binding and DTs are fixed and the driver is reworked to work with both old and new DTs. Note: The driver patch is OK to be backported till 6.2 where the common resource parsing code was introduced. But the DTS patch should not be backported. And I'm not sure about the backporting of the binding. Please test this series on the Meson board with old and new DTs. - Mani Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com> --- Manivannan Sadhasivam (3): dt-bindings: PCI: amlogic: Fix the register name of the DBI region arm64: dts: amlogic: Fix the register name of the 'DBI' region PCI: meson: Fix parsing the DBI register region .../devicetree/bindings/pci/amlogic,axg-pcie.yaml | 6 +++--- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++-- arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +- drivers/pci/controller/dwc/pci-meson.c | 18 +++++++++++++++--- drivers/pci/controller/dwc/pcie-designware.c | 12 +++++++----- 5 files changed, 28 insertions(+), 14 deletions(-) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20251031-pci-meson-fix-c8b651bc6662 Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com>

4 days, 14 hours

1
1
0 0

[PATCH v2 1/2] vfio: Fix ksize arg while copying user struct in vfio_df_ioctl_bind_iommufd()

by Raghavendra Rao Ananta

For the cases where user includes a non-zero value in 'token_uuid_ptr' field of 'struct vfio_device_bind_iommufd', the copy_struct_from_user() in vfio_df_ioctl_bind_iommufd() fails with -E2BIG. For the 'minsz' passed, copy_struct_from_user() expects the newly introduced field to be zero-ed, which would be incorrect in this case. Fix this by passing the actual size of the kernel struct. If working with a newer userspace, copy_struct_from_user() would copy the 'token_uuid_ptr' field, and if working with an old userspace, it would zero out this field, thus still retaining backward compatibility. Fixes: 86624ba3b522 ("vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD") Cc: stable(a)vger.kernel.org Signed-off-by: Raghavendra Rao Ananta <rananta(a)google.com> Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/vfio/device_cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c index 480cac3a0c274..8ceca24ac136c 100644 --- a/drivers/vfio/device_cdev.c +++ b/drivers/vfio/device_cdev.c @@ -99,7 +99,7 @@ long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df, return ret; if (user_size < minsz) return -EINVAL; - ret = copy_struct_from_user(&bind, minsz, arg, user_size); + ret = copy_struct_from_user(&bind, sizeof(bind), arg, user_size); if (ret) return ret; -- 2.51.1.930.gacf6e81ea2-goog

4 days, 15 hours

1
0
0 0

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

by Krzysztof Kozlowski

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

4 days, 15 hours

3
9
0 0

[PATCH net] Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()

by Ilia Gavrilov

In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: db08722fc7d4 ("Bluetooth: hci_core: Fix missing instances using HCI_MAX_AD_LENGTH") Cc: stable(a)vger.kernel.org Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov(a)infotecs.ru> --- include/net/bluetooth/mgmt.h | 2 +- net/bluetooth/mgmt.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h index 74edea06985b..4b07ce6dfd69 100644 --- a/include/net/bluetooth/mgmt.h +++ b/include/net/bluetooth/mgmt.h @@ -780,7 +780,7 @@ struct mgmt_adv_pattern { __u8 ad_type; __u8 offset; __u8 length; - __u8 value[31]; + __u8 value[HCI_MAX_AD_LENGTH]; } __packed; #define MGMT_OP_ADD_ADV_PATTERNS_MONITOR 0x0052 diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index a3d16eece0d2..500033b70a96 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -5391,9 +5391,9 @@ static u8 parse_adv_monitor_pattern(struct adv_monitor *m, u8 pattern_count, for (i = 0; i < pattern_count; i++) { offset = patterns[i].offset; length = patterns[i].length; - if (offset >= HCI_MAX_EXT_AD_LENGTH || - length > HCI_MAX_EXT_AD_LENGTH || - (offset + length) > HCI_MAX_EXT_AD_LENGTH) + if (offset >= HCI_MAX_AD_LENGTH || + length > HCI_MAX_AD_LENGTH || + (offset + length) > HCI_MAX_AD_LENGTH) return MGMT_STATUS_INVALID_PARAMS; p = kmalloc(sizeof(*p), GFP_KERNEL); -- 2.39.5

4 days, 16 hours

3
5
0 0

[PATCH v2 0/1] Bluetooth: btusb: add default nvm file

by Shuai Zhang

this patch adds support for default NVM file Changes v2: - Add log for failed default nvm file request. - Added Cc: stable(a)vger.kernel.org to comply with stable kernel rules. - Link to v1: https://lore.kernel.org/all/20251028120550.2225434-1-quic_shuaz@quicinc.com/ Shuai Zhang (1): Bluetooth: btusb: add default nvm file drivers/bluetooth/btusb.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) -- 2.34.1

4 days, 16 hours

2
2
0 0

[PATCH v3] usb: storage: Fix memory leak in USB bulk transport

by Desnes Nunes

A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable(a)vger.kernel.org Signed-off-by: Desnes Nunes <desnesn(a)redhat.com> --- V2->V3: Changed memset to use sizeof(buf) and added a comment about the leak V1->V2: Used the same code style found on usb_stor_Bulk_transport() drivers/usb/storage/transport.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c index 1aa1bd26c81f..9a4bf86e7b6a 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -1200,7 +1200,23 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us) US_BULK_CS_WRAP_LEN && bcs->Signature == cpu_to_le32(US_BULK_CS_SIGN)) { + unsigned char buf[US_BULK_CS_WRAP_LEN]; + usb_stor_dbg(us, "Device skipped data phase\n"); + + /* + * Devices skipping data phase might leave CSW data in srb's + * transfer buffer. Zero it to prevent USB protocol leakage. + */ + sg = NULL; + offset = 0; + memset(buf, 0, sizeof(buf)); + if (usb_stor_access_xfer_buf(buf, + US_BULK_CS_WRAP_LEN, srb, &sg, + &offset, TO_XFER_BUF) != + US_BULK_CS_WRAP_LEN) + usb_stor_dbg(us, "Failed to clear CSW data\n"); + scsi_set_resid(srb, transfer_length); goto skipped_data_phase; } -- 2.51.0

4 days, 17 hours

2
1
0 0

[PATCH] gpiolib: Fix a null-ptr-deref in gpiolib_seq_stop()

by Ilia Gavrilov

Syzkaller reports a null-ptr-deref in gpiolib_seq_stop() [1] If the memory allocation for priv variable in gpiolib_seq_start() fails, then s->private remains uninitialized, which leads to a null pointer dereference to s->private in gpiolib_seq_stop(). [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10120 Comm: gpio_seq_stop Not tainted 6.12.53 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:gpiolib_seq_stop+0x4c/0xd0 Code: 48 c1 ea 03 80 3c 02 00 0f 85 95 00 00 00 48 8b 9b e0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 5d 8b RSP: 0018:ffffc90019f2fad8 EFLAGS: 00010247 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000400 RDX: 0000000000000000 RSI: ffffffff84c57bfe RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000dc0 R09: 00000000ffffffff R10: ffffffff8e3865b3 R11: 0000000000000001 R12: 0000000000000000 R13: ffffffff8bd9da80 R14: 0000000000010000 R15: 0000000000000000 FS: 00007fb9a07cf6c0(0000) GS:ffff888131600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004c2018 CR3: 00000000264c6000 CR4: 00000000000006f0 Call Trace: <TASK> seq_read_iter+0x610/0x1290 seq_read+0x3a4/0x570 ? __pfx_seq_read+0x10/0x10 full_proxy_read+0x12a/0x1a0 ? __pfx_full_proxy_read+0x10/0x10 vfs_read+0x1e2/0xcf0 ? __fget_files+0x23a/0x3f0 ? __pfx_lock_release+0x10/0x10 ? fdget_pos+0x24c/0x360 ? __pfx_vfs_read+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 ? __fget_files+0x244/0x3f0 ksys_read+0x12f/0x260 ? __pfx_ksys_read+0x10/0x10 do_syscall_64+0xcd/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller Fixes: e348544f7994 ("gpio: protect the list of GPIO devices with SRCU") Reported-by: syzbot+b95d0c98f01e7a95da72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b95d0c98f01e7a95da72 Cc: stable(a)vger.kernel.org # 6.9+ Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov(a)infotecs.ru> --- drivers/gpio/gpiolib.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 9952e412da50..13cf9f4bdc6d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -5298,7 +5298,7 @@ static void *gpiolib_seq_start(struct seq_file *s, loff_t *pos) priv = kzalloc(sizeof(*priv), GFP_KERNEL); if (!priv) - return NULL; + return ERR_PTR(-ENOMEM); s->private = priv; if (*pos > 0) @@ -5331,8 +5331,11 @@ static void gpiolib_seq_stop(struct seq_file *s, void *v) { struct gpiolib_seq_priv *priv = s->private; - srcu_read_unlock(&gpio_devices_srcu, priv->idx); - kfree(priv); + if (!IS_ERR(v)) { + srcu_read_unlock(&gpio_devices_srcu, priv->idx); + kfree(priv); + } + s->private = NULL; } static int gpiolib_seq_show(struct seq_file *s, void *v) -- 2.39.5

4 days, 17 hours

1
0
0 0

[PATCH 0/3] SDM630/660: Add missing MDSS reset

by unknown＠example.com

Since kernel 6.17 display stack needs to reset the hardware properly to ensure that we don't run into issues with the hardware configured by the bootloader. MDSS reset is necessary to have working display when the bootloader has already initialized it for the boot splash screen. Signed-off-by: Alexey Minnekhanov <<alexeymin(a)postmarketos.org>> --- Alexey Minnekhanov (3): dt-bindings: clock: mmcc-sdm660: Add missing MDSS reset clk: qcom: mmcc-sdm660: Add missing MDSS reset arm64: dts: qcom: sdm630: Add missing MDSS reset arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 + drivers/clk/qcom/mmcc-sdm660.c | 1 + include/dt-bindings/clock/qcom,mmcc-sdm660.h | 1 + 3 files changed, 3 insertions(+) --- base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6 change-id: 20251031-sdm660-mdss-reset-015a46a238b5 Best regards, -- Alexey Minnekhanov <<alexeymin(a)postmarketos.org>>

4 days, 17 hours

5
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror