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

[PATCH] pmdomain: imx: Fix reference count leak in imx_gpc_probe()

by Wentao Liang

of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() calls in imx_gpc_probe() to avoid reference count leak. This commit fixes the following issues: 1. Add of_node_put(pgc_node) before returning from imx_gpc_probe() 2. Use goto pattern to consolidate error handling Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/pmdomain/imx/gpc.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c index f18c7e6e75dd..754c60effc8a 100644 --- a/drivers/pmdomain/imx/gpc.c +++ b/drivers/pmdomain/imx/gpc.c @@ -416,8 +416,10 @@ static int imx_gpc_probe(struct platform_device *pdev) return 0; base = devm_platform_ioremap_resource(pdev, 0); - if (IS_ERR(base)) - return PTR_ERR(base); + if (IS_ERR(base)) { + ret = PTR_ERR(base); + goto err_free; + } regmap = devm_regmap_init_mmio_clk(&pdev->dev, NULL, base, &imx_gpc_regmap_config); @@ -425,7 +427,7 @@ static int imx_gpc_probe(struct platform_device *pdev) ret = PTR_ERR(regmap); dev_err(&pdev->dev, "failed to init regmap: %d\n", ret); - return ret; + goto err_free; } /* @@ -460,29 +462,33 @@ static int imx_gpc_probe(struct platform_device *pdev) int domain_index; ipg_clk = devm_clk_get(&pdev->dev, "ipg"); - if (IS_ERR(ipg_clk)) - return PTR_ERR(ipg_clk); + if (IS_ERR(ipg_clk)) { + ret = PTR_ERR(ipg_clk); + goto err_free; + } ipg_rate_mhz = clk_get_rate(ipg_clk) / 1000000; for_each_child_of_node_scoped(pgc_node, np) { ret = of_property_read_u32(np, "reg", &domain_index); if (ret) - return ret; + goto err_free; if (domain_index >= of_id_data->num_domains) continue; pd_pdev = platform_device_alloc("imx-pgc-power-domain", domain_index); - if (!pd_pdev) - return -ENOMEM; + if (!pd_pdev) { + ret = -ENOMEM; + goto err_free; + } ret = platform_device_add_data(pd_pdev, &imx_gpc_domains[domain_index], sizeof(imx_gpc_domains[domain_index])); if (ret) { platform_device_put(pd_pdev); - return ret; + goto err_free; } domain = pd_pdev->dev.platform_data; domain->regmap = regmap; @@ -495,12 +501,17 @@ static int imx_gpc_probe(struct platform_device *pdev) ret = platform_device_add(pd_pdev); if (ret) { platform_device_put(pd_pdev); - return ret; + goto err_free; } } } + of_node_put(pgc_node); return 0; + +err_free: + of_node_put(pgc_node); + return ret; } static void imx_gpc_remove(struct platform_device *pdev) -- 2.34.1

1 day, 15 hours

3
2
0 0

[PATCH v3 1/2] intel_th: fix device leak on output open()

by Johan Hovold

Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open(). Fixes: 39f4034693b7 ("intel_th: Add driver infrastructure for Intel(R) Trace Hub devices") Fixes: 6d5925b667e4 ("intel_th: Fix error handling in intel_th_output_open") Cc: stable(a)vger.kernel.org # 4.4: 6d5925b667e4 Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Ma Ke <make24(a)iscas.ac.cn> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/hwtracing/intel_th/core.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c index 591b7c12aae5..d9c17214d3dc 100644 --- a/drivers/hwtracing/intel_th/core.c +++ b/drivers/hwtracing/intel_th/core.c @@ -810,9 +810,12 @@ static int intel_th_output_open(struct inode *inode, struct file *file) int err; dev = bus_find_device_by_devt(&intel_th_bus, inode->i_rdev); - if (!dev || !dev->driver) { + if (!dev) + return -ENODEV; + + if (!dev->driver) { err = -ENODEV; - goto out_no_device; + goto out_put_device; } thdrv = to_intel_th_driver(dev->driver); @@ -836,12 +839,22 @@ static int intel_th_output_open(struct inode *inode, struct file *file) out_put_device: put_device(dev); -out_no_device: + return err; } +static int intel_th_output_release(struct inode *inode, struct file *file) +{ + struct intel_th_device *thdev = file->private_data; + + put_device(&thdev->dev); + + return 0; +} + static const struct file_operations intel_th_output_fops = { .open = intel_th_output_open, + .release = intel_th_output_release, .llseek = noop_llseek, }; -- 2.52.0

1 day, 15 hours

1
0
0 0

[PATCH 1/1] PCI: Use resource_set_range() that correctly sets ->end

by Ilpo Järvinen

__pci_read_base() sets resource start and end addresses when resource is larger than 4G but pci_bus_addr_t or resource_size_t are not capable of representing 64-bit PCI addresses. This creates a problematic resource that has non-zero flags but the start and end addresses do not yield to resource size of 0 but 1. Replace custom resource addresses setup with resource_set_range() that correctly sets end address as -1 which results in resource_size() returning 0. For consistency, also use resource_set_range() in the other branch that does size based resource setup. Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB") Link: https://lore.kernel.org/all/20251207215359.28895-1-ansuelsmth@gmail.com/T/#… Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org Cc: Christian Marangi <ansuelsmth(a)gmail.com> --- drivers/pci/probe.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 124d2d309c58..b8294a2f11f9 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -287,8 +287,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, if ((sizeof(pci_bus_addr_t) < 8 || sizeof(resource_size_t) < 8) && sz64 > 0x100000000ULL) { res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED; - res->start = 0; - res->end = 0; + resource_set_range(res, 0, 0); pci_err(dev, "%s: can't handle BAR larger than 4GB (size %#010llx)\n", res_name, (unsigned long long)sz64); goto out; @@ -297,8 +296,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, if ((sizeof(pci_bus_addr_t) < 8) && l) { /* Above 32-bit boundary; try to reallocate */ res->flags |= IORESOURCE_UNSET; - res->start = 0; - res->end = sz64 - 1; + resource_set_range(res, 0, sz64); pci_info(dev, "%s: can't handle BAR above 4GB (bus address %#010llx)\n", res_name, (unsigned long long)l64); goto out; base-commit: 43dfc13ca972988e620a6edb72956981b75ab6b0 -- 2.39.5

1 day, 15 hours

2
1
0 0

[PATCH] fsi: master-gpio: Fix reference count leak in probe error path

by Wentao Liang

The function of_node_get() returns a node pointer with its refcount incremented, but in the error path of the fsi_master_gpio_probe(), this reference is not released before freeing the master structure, causing a refcount leak. Add the missing of_node_put() in the error handling path to properly release the device tree node reference. Fixes: 8ef9ccf81044 ("fsi: master-gpio: Add missing release function") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/fsi/fsi-master-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 69de0b5b9cbd..ae9e156284d0 100644 --- a/drivers/fsi/fsi-master-gpio.c +++ b/drivers/fsi/fsi-master-gpio.c @@ -861,6 +861,7 @@ static int fsi_master_gpio_probe(struct platform_device *pdev) } return 0; err_free: + of_node_put(master->master.dev.of_node); kfree(master); return rc; } -- 2.34.1

1 day, 15 hours

2
1
0 0

[PATCH] resource: handle wrong resource_size value on zero start/end resource

by Christian Marangi

Commit 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for "memory-region"") uncovered a massive problem with the usage of resource_size() helper. The reported commit caused a regression with ath11k WiFi firmware loading and the change was just a simple replacement of duplicate code with a new helper of_reserved_mem_region_to_resource(). On reworking this, in the commit also a check for the presence of the node was replaced with resource_size(&res). This was done following the logic that if the node wasn't present then it's expected that also the resource_size is zero, mimicking the same if-else logic. This was also the reason the regression was mostly hard to catch at first sight as the rework is correctly done given the assumption on the used helpers. BUT this is actually not the case. On further inspection on resource_size() it was found that it NEVER actually returns 0. Even if the resource value of start and end are 0, the return value of resource_size() will ALWAYS be 1, resulting in the broken if-else condition ALWAYS going in the first if condition. This was simply confirmed by reading the resource_size() logic: return res->end - res->start + 1; Given the confusion, also other case of such usage were searched in the kernel and with great suprise it seems LOTS of place assume resource_size() should return zero in the context of the resource start and end set to 0. Quoting for example comments in drivers/vfio/pci/vfio_pci_core.c: /* * The PCI core shouldn't set up a resource with a * type but zero size. But there may be bugs that * cause us to do that. */ if (!resource_size(res)) goto no_mmap; It really seems resource_size() was tought with the assumption that resource struct was always correctly initialized before calling it and never set to zero. But across the year this got lost and now there are lots of driver that assume resource_size() returns 0 if start and end are also 0. To better handle this and make resource_size() returns correct value in such case, add a simple check and return 0 if both resource start and resource end are zero. Cc: Rob Herring (Arm) <robh(a)kernel.org> Cc: stable(a)vger.kernel.org Fixes: 1a4e564b7db9 ("resource: add resource_size()") Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> --- include/linux/ioport.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 9afa30f9346f..1b8ce62255db 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -288,6 +288,9 @@ static inline void resource_set_range(struct resource *res, static inline resource_size_t resource_size(const struct resource *res) { + if (!res->start && !res->end) + return 0; + return res->end - res->start + 1; } static inline unsigned long resource_type(const struct resource *res) -- 2.51.0

1 day, 15 hours

3
10
0 0

PROBLEM: hwclock busted w/ M48T59 RTC (regression)

by Nick Bowler

Hi, After a stable kernel update, the hwclock command seems no longer functional on my SPARC system with an ST M48T59Y-70PC1 RTC: # hwclock [...long delay...] hwclock: select() to /dev/rtc0 to wait for clock tick timed out On prior kernels, there is no problem: # hwclock 2025-10-22 22:21:04.806992-04:00 I reproduced the same failure on 6.18-rc2 and bisected to this commit: commit 795cda8338eab036013314dbc0b04aae728880ab Author: Esben Haabendal <esben(a)geanix.com> Date: Fri May 16 09:23:35 2025 +0200 rtc: interface: Fix long-standing race when setting alarm This commit was backported to all current 6.x stable branches, as well as 5.15.x, so they all have the same regression. Reverting this commit on top of 6.18-rc2 corrects the problem. Let me know if you need any more info! Thanks, Nick

1 day, 16 hours

4
7
0 0

[PATCH] powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded

by Nam Cao

Nilay reported that since commit daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()"), the NVMe driver cannot enable MSI-X when the device's MSI-X table size is larger than the firmware's MSI quota for the device. This is because the commit changes how rtas_prepare_msi_irqs() is called: - Before, it is called when interrupts are allocated at the global interrupt domain with nvec_in being the number of allocated interrupts. rtas_prepare_msi_irqs() can return a positive number and the allocation will be retried. - Now, it is called at the creation of per-device interrupt domain with nvec_in being the number of interrupts that the device supports. If rtas_prepare_msi_irqs() returns positive, domain creation just fails. For Nilay's NVMe driver case, rtas_prepare_msi_irqs() returns a positive number (the quota). This causes per-device interrupt domain creation to fail and thus the NVMe driver cannot enable MSI-X. Rework to make this scenario works again: - pseries_msi_ops_prepare() only prepares as many interrupts as the quota permit. - pseries_irq_domain_alloc() fails if the device's quota is exceeded. Now, if the quota is exceeded, pseries_msi_ops_prepare() will only prepare as allowed by the quota. If device drivers attempt to allocate more interrupts than the quota permits, pseries_irq_domain_alloc() will return an error code and msi_handle_pci_fail() will allow device drivers a retry. Reported-by: Nilay Shroff <nilay(a)inux.ibm.com> Closes: https://lore.kernel.org/linuxppc-dev/6af2c4c2-97f6-4758-be33-256638ef39e5@l… Fixes: daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Acked-by: Nilay Shroff <nilay(a)inux.ibm.com> Cc: stable(a)vger.kernel.org --- arch/powerpc/platforms/pseries/msi.c | 42 ++++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c index a82aaa786e9e..8898a968a59b 100644 --- a/arch/powerpc/platforms/pseries/msi.c +++ b/arch/powerpc/platforms/pseries/msi.c @@ -19,6 +19,11 @@ #include "pseries.h" +struct pseries_msi_device { + unsigned int msi_quota; + unsigned int msi_used; +}; + static int query_token, change_token; #define RTAS_QUERY_FN 0 @@ -433,8 +438,26 @@ static int pseries_msi_ops_prepare(struct irq_domain *domain, struct device *dev struct msi_domain_info *info = domain->host_data; struct pci_dev *pdev = to_pci_dev(dev); int type = (info->flags & MSI_FLAG_PCI_MSIX) ? PCI_CAP_ID_MSIX : PCI_CAP_ID_MSI; + int ret; + + struct pseries_msi_device *pseries_dev __free(kfree) + = kmalloc(sizeof(*pseries_dev), GFP_KERNEL); + if (!pseries_dev) + return -ENOMEM; + + ret = rtas_prepare_msi_irqs(pdev, nvec, type, arg); + if (ret > 0) { + nvec = ret; + ret = rtas_prepare_msi_irqs(pdev, nvec, type, arg); + } + if (ret < 0) + return ret; - return rtas_prepare_msi_irqs(pdev, nvec, type, arg); + pseries_dev->msi_quota = nvec; + pseries_dev->msi_used = 0; + + arg->scratchpad[0].ptr = no_free_ptr(pseries_dev); + return 0; } /* @@ -443,9 +466,13 @@ static int pseries_msi_ops_prepare(struct irq_domain *domain, struct device *dev */ static void pseries_msi_ops_teardown(struct irq_domain *domain, msi_alloc_info_t *arg) { + struct pseries_msi_device *pseries_dev = arg->scratchpad[0].ptr; struct pci_dev *pdev = to_pci_dev(domain->dev); rtas_disable_msi(pdev); + + WARN_ON(pseries_dev->msi_used); + kfree(pseries_dev); } static void pseries_msi_shutdown(struct irq_data *d) @@ -546,12 +573,18 @@ static int pseries_irq_domain_alloc(struct irq_domain *domain, unsigned int virq unsigned int nr_irqs, void *arg) { struct pci_controller *phb = domain->host_data; + struct pseries_msi_device *pseries_dev; msi_alloc_info_t *info = arg; struct msi_desc *desc = info->desc; struct pci_dev *pdev = msi_desc_to_pci_dev(desc); int hwirq; int i, ret; + pseries_dev = info->scratchpad[0].ptr; + + if (pseries_dev->msi_used + nr_irqs > pseries_dev->msi_quota) + return -ENOSPC; + hwirq = rtas_query_irq_number(pci_get_pdn(pdev), desc->msi_index); if (hwirq < 0) { dev_err(&pdev->dev, "Failed to query HW IRQ: %d\n", hwirq); @@ -567,9 +600,10 @@ static int pseries_irq_domain_alloc(struct irq_domain *domain, unsigned int virq goto out; irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i, - &pseries_msi_irq_chip, domain->host_data); + &pseries_msi_irq_chip, pseries_dev); } + pseries_dev->msi_used++; return 0; out: @@ -582,9 +616,11 @@ static void pseries_irq_domain_free(struct irq_domain *domain, unsigned int virq unsigned int nr_irqs) { struct irq_data *d = irq_domain_get_irq_data(domain, virq); - struct pci_controller *phb = irq_data_get_irq_chip_data(d); + struct pseries_msi_device *pseries_dev = irq_data_get_irq_chip_data(d); + struct pci_controller *phb = domain->host_data; pr_debug("%s bridge %pOF %d #%d\n", __func__, phb->dn, virq, nr_irqs); + pseries_dev->msi_used -= nr_irqs; irq_domain_free_irqs_parent(domain, virq, nr_irqs); } -- 2.47.3

1 day, 17 hours

1
0
0 0

[PATCH] nvme-pci: add quirk for Wodposit WPBSNM8-256GTP to disable secondary temp thresholds

by Ilikara Zheng

Secondary temperature thresholds (temp2_{min,max}) were not reported properly on this NVMe SSD. This resulted in an error while attempting to read these values with sensors(1): ERROR: Can't get value of subfeature temp2_min: I/O error ERROR: Can't get value of subfeature temp2_max: I/O error Add the device to the nvme_id_table with the NVME_QUIRK_NO_SECONDARY_TEMP_THRESH flag to suppress access to all non- composite temperature thresholds. Cc: stable(a)vger.kernel.org Signed-off-by: Ilikara Zheng <ilikara(a)aosc.io> --- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index e5ca8301bb8b..31049f33f27d 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3997,6 +3997,8 @@ static const struct pci_device_id nvme_id_table[] = { .driver_data = NVME_QUIRK_NO_DEEPEST_PS, }, { PCI_DEVICE(0x1e49, 0x0041), /* ZHITAI TiPro7000 NVMe SSD */ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, }, + { PCI_DEVICE(0x1fa0, 0x2283), /* Wodposit WPBSNM8-256GTP */ + .driver_data = NVME_QUIRK_NO_SECONDARY_TEMP_THRESH, }, { PCI_DEVICE(0x025e, 0xf1ac), /* SOLIDIGM P44 pro SSDPFKKW020X7 */ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, }, { PCI_DEVICE(0xc0a9, 0x540a), /* Crucial P2 */ -- 2.52.0

1 day, 17 hours

2
1
0 0

FAILED: patch "[PATCH] xhci: dbgtty: fix device unregister" 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 1f73b8b56cf35de29a433aee7bfff26cea98be3f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120110-coastal-litigator-8952@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb(a)chromium.org> Date: Wed, 19 Nov 2025 21:29:09 +0000 Subject: [PATCH] xhci: dbgtty: fix device unregister MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index b7f95565524d..57cdda4e09c8 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -550,6 +550,12 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + tty_vhangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;

1 day, 17 hours

2
1
0 0

FAILED: patch "[PATCH] mptcp: Initialise rcv_mss before calling" 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 f07f4ea53e22429c84b20832fa098b5ecc0d4e35 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120333-undamaged-punctual-31dc@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f07f4ea53e22429c84b20832fa098b5ecc0d4e35 Mon Sep 17 00:00:00 2001 From: Kuniyuki Iwashima <kuniyu(a)google.com> Date: Tue, 25 Nov 2025 19:53:29 +0000 Subject: [PATCH] mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose(). syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0] We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0"). Let's apply the same fix to mptcp_do_fastclose(). [0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK> Fixes: ae155060247b ("mptcp: fix duplicate reset on fastclose") Reported-by: syzbot+3a92d359bc2ec6255a33(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69260882.a70a0220.d98e3.00b4.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu(a)google.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251125195331.309558-1-kuniyu@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 8abb425d8b5f..1e413426deee 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2798,6 +2798,12 @@ static void mptcp_do_fastclose(struct sock *sk) goto unlock; subflow->send_fastclose = 1; + + /* Initialize rcv_mss to TCP_MIN_MSS to avoid division by 0 + * issue in __tcp_select_window(), see tcp_disconnect(). + */ + inet_csk(ssk)->icsk_ack.rcv_mss = TCP_MIN_MSS; + tcp_send_active_reset(ssk, ssk->sk_allocation, SK_RST_REASON_TCP_ABORT_ON_CLOSE); unlock:

1 day, 17 hours

2
1
0 0

Performance regressions introduced via Revert "cpuidle: menu: Avoid discarding useful information" on 5.15 LTS

by Harshvardhan Jha

Hi there, While running performance benchmarks for the 5.15.196 LTS tags , it was observed that several regressions across different benchmarks is being introduced when compared to the previous 5.15.193 kernel tag. Running an automated bisect on both of them narrowed down the culprit commit to: - 5666bcc3c00f7 Revert "cpuidle: menu: Avoid discarding useful information" for 5.15 Regressions on 5.15.196 include: -9.3% : Phoronix pts/sqlite using 2 processes on OnPrem X6-2 -6.3% : Phoronix system/sqlite on OnPrem X6-2 -18% : rds-stress -M 1 (readonly rdma-mode) metrics with 1 depth & 1 thread & 1M buffer size on OnPrem X6-2 -4 -> -8% : rds-stress -M 2 (writeonly rdma-mode) metrics with 1 depth & 1 thread & 1M buffer size on OnPrem X6-2 Up to -30% : Some Netpipe metrics on OnPrem X5-2 The culprit commits' messages mention that these reverts were done due to performance regressions introduced in Intel Jasper Lake systems but this revert is causing issues in other systems unfortunately. I wanted to know the maintainers' opinion on how we should proceed in order to fix this. If we reapply it'll bring back the previous regressions on Jasper Lake systems and if we don't revert it then it's stuck with current regressions. If this problem has been reported before and a fix is in the works then please let me know I shall follow developments to that mail thread. Thanks & Regards, Harshvardhan

1 day, 18 hours

3
4
0 0

FAILED: patch "[PATCH] mptcp: Initialise rcv_mss before calling" 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 f07f4ea53e22429c84b20832fa098b5ecc0d4e35 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120334-preamble-cobalt-4ca0@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f07f4ea53e22429c84b20832fa098b5ecc0d4e35 Mon Sep 17 00:00:00 2001 From: Kuniyuki Iwashima <kuniyu(a)google.com> Date: Tue, 25 Nov 2025 19:53:29 +0000 Subject: [PATCH] mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose(). syzbot reported divide-by-zero in __tcp_select_window() by MPTCP socket. [0] We had a similar issue for the bare TCP and fixed in commit 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0"). Let's apply the same fix to mptcp_do_fastclose(). [0]: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336 Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00 RSP: 0018:ffffc90003017640 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028 R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0 Call Trace: <TASK> tcp_select_window net/ipv4/tcp_output.c:281 [inline] __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568 tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline] tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836 mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793 mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253 mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776 mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3bd/0x520 net/socket.c:2244 __do_sys_sendto net/socket.c:2251 [inline] __se_sys_sendto net/socket.c:2247 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2247 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66e998f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006 </TASK> Fixes: ae155060247b ("mptcp: fix duplicate reset on fastclose") Reported-by: syzbot+3a92d359bc2ec6255a33(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69260882.a70a0220.d98e3.00b4.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu(a)google.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251125195331.309558-1-kuniyu@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 8abb425d8b5f..1e413426deee 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2798,6 +2798,12 @@ static void mptcp_do_fastclose(struct sock *sk) goto unlock; subflow->send_fastclose = 1; + + /* Initialize rcv_mss to TCP_MIN_MSS to avoid division by 0 + * issue in __tcp_select_window(), see tcp_disconnect(). + */ + inet_csk(ssk)->icsk_ack.rcv_mss = TCP_MIN_MSS; + tcp_send_active_reset(ssk, ssk->sk_allocation, SK_RST_REASON_TCP_ABORT_ON_CLOSE); unlock:

1 day, 19 hours

3
2
0 0

[PATCH 0/4] drm: Revert and fix enable/disable sequence

by Tomi Valkeinen

Changing the enable/disable sequence in commit c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable") has caused regressions on multiple platforms: R-Car, MCDE, Rockchip. This is an alternate series to Linus' series: https://lore.kernel.org/all/20251202-mcde-drm-regression-thirdfix-v6-0-f1bf… This series first reverts the original commit and reverts a fix for mediatek which is no longer needed. It then exposes helper functions from DRM core, and finally implements the new sequence only in the tidss driver. There is one more fix in upstream for the original commit, commit 5d91394f2361 ("drm/exynos: fimd: Guard display clock control with runtime PM calls"), but I have not reverted that one as it looks like a valid patch in its own. I added Cc stable v6.17+ to all patches, but I didn't add Fixes tags, as I wasn't sure what should they point to. But I could perhaps add Fixes: <original commit> to all of these. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> --- Linus Walleij (1): drm/atomic-helper: Export and namespace some functions Tomi Valkeinen (3): Revert "drm/atomic-helper: Re-order bridge chain pre-enable and post-disable" Revert "drm/mediatek: dsi: Fix DSI host and panel bridge pre-enable order" drm/tidss: Fix enable/disable order drivers/gpu/drm/drm_atomic_helper.c | 122 ++++++++++++++---- drivers/gpu/drm/mediatek/mtk_dsi.c | 6 - drivers/gpu/drm/tidss/tidss_kms.c | 30 ++++- include/drm/drm_atomic_helper.h | 22 ++++ include/drm/drm_bridge.h | 249 ++++++++++-------------------------- 5 files changed, 214 insertions(+), 215 deletions(-) --- base-commit: 88e721ab978a86426aa08da520de77430fa7bb84 change-id: 20251205-drm-seq-fix-b4ed1f56604b Best regards, -- Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>

1 day, 19 hours

5
10
0 0

[PATCH v1 1/4] mm/hugetlb: fix hugetlb_pmd_shared()

by David Hildenbrand (Red Hat)

We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared(). Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") Cc: <stable(a)vger.kernel.org> Cc: Liu Shixin <liushixin2(a)huawei.com> Signed-off-by: David Hildenbrand (Red Hat) <david(a)kernel.org> --- include/linux/hugetlb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 019a1c5281e4e..03c8725efa289 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -1326,7 +1326,7 @@ static inline __init void hugetlb_cma_reserve(int order) #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING static inline bool hugetlb_pmd_shared(pte_t *pte) { - return page_count(virt_to_page(pte)) > 1; + return ptdesc_pmd_is_shared(virt_to_ptdesc(pte)); } #else static inline bool hugetlb_pmd_shared(pte_t *pte) -- 2.52.0

1 day, 19 hours

5
6
0 0

[PATCH v2] media: uvcvideo: Fix support for V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX

by Ricardo Ribalda

The VIDIOC_G_EXT_CTRLS with which V4L2_CTRL_WHICH_(MIN|MAX)_VAL can only work for controls that have previously announced support for it. This patch fixes the following v4l2-compliance error: info: checking extended control 'User Controls' (0x00980001) fail: v4l2-test-controls.cpp(980): ret != EINVAL (got 13) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Fixes: 39d2c891c96e ("media: uvcvideo: support V4L2_CTRL_WHICH_MIN/MAX_VAL") Cc: stable(a)vger.kernel.org Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v2, Thanks Laurent: - Remove redundant ioctl check - CodeStyle - Link to v1: https://lore.kernel.org/r/20251028-uvc-fix-which-v1-1-a7e6b82672a3@chromium… --- drivers/media/usb/uvc/uvc_ctrl.c | 14 ++++++++++++-- drivers/media/usb/uvc/uvc_v4l2.c | 10 ++++++---- drivers/media/usb/uvc/uvcvideo.h | 2 +- 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index 2905505c240c060e5034ea12d33b59d5702f2e1f..2738ef74c7373b185b67611da57610fd0b442080 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1432,7 +1432,7 @@ static bool uvc_ctrl_is_readable(u32 which, struct uvc_control *ctrl, * auto_exposure=1, exposure_time_absolute=251. */ int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, - const struct v4l2_ext_controls *ctrls, + const struct v4l2_ext_controls *ctrls, u32 which, unsigned long ioctl) { struct uvc_control_mapping *master_map = NULL; @@ -1442,14 +1442,24 @@ int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, s32 val; int ret; int i; + /* + * There is no need to check the ioctl, all the ioctls except + * VIDIOC_G_EXT_CTRLS use which=V4L2_CTRL_WHICH_CUR_VAL. + */ + bool is_which_min_max = which == V4L2_CTRL_WHICH_MIN_VAL || + which == V4L2_CTRL_WHICH_MAX_VAL; if (__uvc_query_v4l2_class(chain, v4l2_id, 0) >= 0) - return -EACCES; + return is_which_min_max ? -EINVAL : -EACCES; ctrl = uvc_find_control(chain, v4l2_id, &mapping); if (!ctrl) return -EINVAL; + if ((!(ctrl->info.flags & UVC_CTRL_FLAG_GET_MIN) || + !(ctrl->info.flags & UVC_CTRL_FLAG_GET_MAX)) && is_which_min_max) + return -EINVAL; + if (ioctl == VIDIOC_G_EXT_CTRLS) return uvc_ctrl_is_readable(ctrls->which, ctrl, mapping); diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index 9e4a251eca88085a1b4e0e854370015855be92ee..30c160daed8cb057b31ec00d665107dfdf4be1dc 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -765,14 +765,15 @@ static int uvc_ioctl_query_ext_ctrl(struct file *file, void *priv, static int uvc_ctrl_check_access(struct uvc_video_chain *chain, struct v4l2_ext_controls *ctrls, - unsigned long ioctl) + u32 which, unsigned long ioctl) { struct v4l2_ext_control *ctrl = ctrls->controls; unsigned int i; int ret = 0; for (i = 0; i < ctrls->count; ++ctrl, ++i) { - ret = uvc_ctrl_is_accessible(chain, ctrl->id, ctrls, ioctl); + ret = uvc_ctrl_is_accessible(chain, ctrl->id, ctrls, which, + ioctl); if (ret) break; } @@ -806,7 +807,7 @@ static int uvc_ioctl_g_ext_ctrls(struct file *file, void *priv, which = V4L2_CTRL_WHICH_CUR_VAL; } - ret = uvc_ctrl_check_access(chain, ctrls, VIDIOC_G_EXT_CTRLS); + ret = uvc_ctrl_check_access(chain, ctrls, which, VIDIOC_G_EXT_CTRLS); if (ret < 0) return ret; @@ -840,7 +841,8 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh *handle, if (!ctrls->count) return 0; - ret = uvc_ctrl_check_access(chain, ctrls, ioctl); + ret = uvc_ctrl_check_access(chain, ctrls, V4L2_CTRL_WHICH_CUR_VAL, + ioctl); if (ret < 0) return ret; diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index ed7bad31f75ca474c1037d666d5310c78dd764df..d583425893a5f716185153a07aae9bfe20182964 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -786,7 +786,7 @@ int uvc_ctrl_get(struct uvc_video_chain *chain, u32 which, struct v4l2_ext_control *xctrl); int uvc_ctrl_set(struct uvc_fh *handle, struct v4l2_ext_control *xctrl); int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id, - const struct v4l2_ext_controls *ctrls, + const struct v4l2_ext_controls *ctrls, u32 which, unsigned long ioctl); int uvc_xu_ctrl_query(struct uvc_video_chain *chain, --- base-commit: c218ce4f98eccf5a40de64c559c52d61e9cc78ee change-id: 20251028-uvc-fix-which-c3ba1fb68ed5 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

1 day, 21 hours

2
1
0 0

[PATCH] staging: rtl8723bs: fix missing status update on sdio_alloc_irq() failure

by Liang Jie

From: Liang Jie <liangjie(a)lixiang.com> The return value of sdio_alloc_irq() was not stored in status. If sdio_alloc_irq() fails after rtw_drv_register_netdev() succeeds, status remains _SUCCESS and the error path skips resource cleanup, while rtw_drv_init() still returns success. Store the return value of sdio_alloc_irq() in status and reuse the existing error handling which relies on status. Cc: stable(a)vger.kernel.org Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Reviewed-by: fanggeng <fanggeng(a)lixiang.com> Signed-off-by: Liang Jie <liangjie(a)lixiang.com> --- drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c index f3caaa857c86..139ace51486d 100644 --- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c +++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c @@ -377,7 +377,8 @@ static int rtw_drv_init( if (status != _SUCCESS) goto free_if1; - if (sdio_alloc_irq(dvobj) != _SUCCESS) + status = sdio_alloc_irq(dvobj); + if (status != _SUCCESS) goto free_if1; status = _SUCCESS; -- 2.25.1

1 day, 21 hours

1
0
0 0

[PATCH 6.18 regression fix] dma-mapping: Fix DMA_BIT_MASK() macro being broken

by Hans de Goede

After commit a50f7456f853 ("dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope"), the DMA_BIT_MASK() macro is broken when passed non trivial statements for the value of 'n'. This is caused by the new version missing parenthesis around 'n' when evaluating 'n'. One example of this breakage is the IPU6 driver now crashing due to it getting DMA-addresses with address bit 32 set even though it has tried to set a 32 bit DMA mask. The IPU6 CSI2 engine has a DMA mask of either 31 or 32 bits depending on if it is in secure mode or not and it sets this masks like this: mmu_info->aperture_end = (dma_addr_t)DMA_BIT_MASK(isp->secure_mode ? IPU6_MMU_ADDR_BITS : IPU6_MMU_ADDR_BITS_NON_SECURE); So the 'n' argument here is "isp->secure_mode ? IPU6_MMU_ADDR_BITS : IPU6_MMU_ADDR_BITS_NON_SECURE" which gets expanded into: isp->secure_mode ? IPU6_MMU_ADDR_BITS : IPU6_MMU_ADDR_BITS_NON_SECURE - 1 With the -1 only being applied in the non secure case, causing the secure mode mask to be one 1 bit too large. Fixes: a50f7456f853 ("dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope") Cc: Sakari Ailus <sakari.ailus(a)linux.intel.com> Cc: James Clark <james.clark(a)linaro.org> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- include/linux/dma-mapping.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 2ceda49c609f..aa36a0d1d9df 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -90,7 +90,7 @@ */ #define DMA_MAPPING_ERROR (~(dma_addr_t)0) -#define DMA_BIT_MASK(n) GENMASK_ULL(n - 1, 0) +#define DMA_BIT_MASK(n) GENMASK_ULL((n) - 1, 0) struct dma_iova_state { dma_addr_t addr; -- 2.52.0

1 day, 22 hours

4
3
0 0

[PATCH] reset: gpio: suppress bind attributes in sysfs

by Bartosz Golaszewski

This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle. Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller") Cc: stable(a)vger.kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)oss.qualcomm.com> --- drivers/reset/reset-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/reset/reset-gpio.c b/drivers/reset/reset-gpio.c index e5512b3b596b..626c4c639c15 100644 --- a/drivers/reset/reset-gpio.c +++ b/drivers/reset/reset-gpio.c @@ -111,6 +111,7 @@ static struct auxiliary_driver reset_gpio_driver = { .id_table = reset_gpio_ids, .driver = { .name = "reset-gpio", + .suppress_bind_attrs = true, }, }; module_auxiliary_driver(reset_gpio_driver); -- 2.51.0

1 day, 23 hours

3
5
0 0

FAILED: patch "[PATCH] xhci: dbgtty: fix device unregister" 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 1f73b8b56cf35de29a433aee7bfff26cea98be3f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120110-deuce-arrange-e66c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb(a)chromium.org> Date: Wed, 19 Nov 2025 21:29:09 +0000 Subject: [PATCH] xhci: dbgtty: fix device unregister MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index b7f95565524d..57cdda4e09c8 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -550,6 +550,12 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + tty_vhangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;

2 days

2
2
0 0

[PATCH] xfs: Fix a memory leak bug in xfs_buf_item_init()

by Haoxiang Li

xfs_buf_item_get_format() may allocate memory for bip->bli_formats, free the memory in the error path. Fixes: c3d5f0c2fb85 ("xfs: complain if anyone tries to create a too-large buffer log item") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- fs/xfs/xfs_buf_item.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c index 8d85b5eee444..f4c5be67826e 100644 --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -896,6 +896,7 @@ xfs_buf_item_init( map_size = DIV_ROUND_UP(chunks, NBWORD); if (map_size > XFS_BLF_DATAMAP_SIZE) { + xfs_buf_item_free_format(bip); kmem_cache_free(xfs_buf_item_cache, bip); xfs_err(mp, "buffer item dirty bitmap (%u uints) too small to reflect %u bytes!", -- 2.25.1

2 days

2
1
0 0

Re: Patch "dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope" has been added to the 6.17-stable tree

by Nathan Chancellor

On Sun, Dec 07, 2025 at 10:07:49PM -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope > > to the 6.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > dma-mapping-allow-use-of-dma_bit_mask-64-in-global-s.patch > and it can be found in the queue-6.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 51a1912d46ceb70602de50c167e440966b9836f1 > Author: James Clark <james.clark(a)linaro.org> > Date: Thu Oct 30 14:05:27 2025 +0000 > > dma-mapping: Allow use of DMA_BIT_MASK(64) in global scope > > [ Upstream commit a50f7456f853ec3a6f07cbe1d16ad8a8b2501320 ] This change has a pending bug fix, consider waiting to apply this to the stable trees. https://lore.kernel.org/20251207184756.97904-1-johannes.goede@oss.qualcomm.… Cheers, Nathan

2 days, 3 hours

1
0
0 0

[STATUS] stable/linux-5.10.y - f964b940099f9982d723d4c77988d4b0dda9c165

by KernelCI bot

Hello, Status summary for stable/linux-5.10.y Dashboard: https://d.kernelci.org/c/stable/linux-5.10.y/f964b940099f9982d723d4c77988d4… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-5.10.y commit hash: f964b940099f9982d723d4c77988d4b0dda9c165 origin: maestro test start time: 2025-12-06 22:05:22.856000+00:00 Builds: 38 ✅ 0 ❌ 0 ⚠️ Boots: 69 ✅ 0 ❌ 0 ⚠️ Tests: 972 ✅ 267 ❌ 200 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS Hardware: beaglebone-black > Config: multi_v7_defconfig - Architecture/compiler: arm/gcc-14 - ltp last run: https://d.kernelci.org/test/maestro:6934ce3b1ca5bf9d0fd6c4d7 history: > ❌ > ❌ > ✅ > ✅ > ✅ ### UNSTABLE TESTS No unstable tests observed. Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- 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

2 days, 4 hours

1
0
0 0

[STATUS] stable/linux-6.12.y - dcbeffaf66d03968970d7d68ec7800032d00180e

by KernelCI bot

Hello, Status summary for stable/linux-6.12.y Dashboard: https://d.kernelci.org/c/stable/linux-6.12.y/dcbeffaf66d03968970d7d68ec7800… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-6.12.y commit hash: dcbeffaf66d03968970d7d68ec7800032d00180e origin: maestro test start time: 2025-12-06 22:05:24.548000+00:00 Builds: 39 ✅ 0 ❌ 0 ⚠️ Boots: 193 ✅ 0 ❌ 0 ⚠️ Tests: 12053 ✅ 779 ❌ 3133 ⚠️ ### POSSIBLE REGRESSIONS Hardware: dell-latitude-5400-4305U-sarien > Config: x86_64_defconfig+lab-setup+x86-board+kselftest - Architecture/compiler: x86_64/gcc-14 - kselftest.cpufreq.suspend last run: https://d.kernelci.org/test/maestro:6934b9581ca5bf9d0fd66c53 history: > ✅ > ❌ - kselftest.cpufreq.suspend.cpufreq_main_sh last run: https://d.kernelci.org/test/maestro:6935156f1ca5bf9d0fd7d7ed history: > ✅ > ❌ Hardware: dell-latitude-5400-8665U-sarien > Config: x86_64_defconfig+lab-setup+x86-board+kselftest - Architecture/compiler: x86_64/gcc-14 - kselftest.cpufreq.suspend last run: https://d.kernelci.org/test/maestro:6934b9591ca5bf9d0fd66c56 history: > ✅ > ❌ - kselftest.cpufreq.suspend.cpufreq_main_sh last run: https://d.kernelci.org/test/maestro:6934c2821ca5bf9d0fd6a446 history: > ✅ > ❌ Hardware: hp-x360-12b-ca0010nr-n4020-octopus > Config: x86_64_defconfig+lab-setup+x86-board+kselftest - Architecture/compiler: x86_64/gcc-14 - kernelci_wifi_basic last run: https://d.kernelci.org/test/maestro:6934bc4b1ca5bf9d0fd68a11 history: > ✅ > ❌ Hardware: meson-sm1-s905d3-libretech-cc > Config: defconfig+lab-setup+kselftest - Architecture/compiler: arm64/gcc-14 - kselftest.breakpoints last run: https://d.kernelci.org/test/maestro:6934b5901ca5bf9d0fd64a44 history: > ✅ > ❌ Hardware: sun50i-h5-libretech-all-h3-cc > Config: defconfig+lab-setup+kselftest - Architecture/compiler: arm64/gcc-14 - kselftest.arm64 last run: https://d.kernelci.org/test/maestro:6934b58e1ca5bf9d0fd64a2a history: > ✅ > ❌ ### FIXED REGRESSIONS Hardware: mt8186-corsola-steelix-sku131072 > Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y - Architecture/compiler: arm64/gcc-14 - kernelci_watchdog_reset.wdt-reset.wdt-get-timeout last run: https://d.kernelci.org/test/maestro:6934b7ac1ca5bf9d0fd65f2b history: > ❌ > ✅ ### UNSTABLE TESTS Hardware: beaglebone-black > Config: multi_v7_defconfig - Architecture/compiler: arm/gcc-14 - ltp last run: https://d.kernelci.org/test/maestro:6934b4f81ca5bf9d0fd6480d history: > ✅ > ❌ > ❌ > ✅ > ✅ Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- 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

2 days, 4 hours

1
0
0 0

[STATUS] stable/linux-5.15.y - 68efe5a6c16a05391e3d96025b41e9bf573f968c

by KernelCI bot

Hello, Status summary for stable/linux-5.15.y Dashboard: https://d.kernelci.org/c/stable/linux-5.15.y/68efe5a6c16a05391e3d96025b41e9… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-5.15.y commit hash: 68efe5a6c16a05391e3d96025b41e9bf573f968c origin: maestro test start time: 2025-12-06 22:05:23.274000+00:00 Builds: 34 ✅ 4 ❌ 0 ⚠️ Boots: 45 ✅ 0 ❌ 0 ⚠️ Tests: 855 ✅ 252 ❌ 887 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS Hardware: beaglebone-black > Config: multi_v7_defconfig - Architecture/compiler: arm/gcc-14 - ltp last run: https://d.kernelci.org/test/maestro:6934ae5d1ca5bf9d0fd6352c history: > ❌ > ❌ > ❌ > ✅ > ✅ ### UNSTABLE TESTS No unstable tests observed. This branch has 4 pre-existing build issues. See details in the dashboard. Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- 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

2 days, 4 hours

1
0
0 0

[STATUS] stable/linux-6.6.y - 5fa4793a2d2d70ad08b85387b41020f1fcc2d19e

by KernelCI bot

Hello, Status summary for stable/linux-6.6.y Dashboard: https://d.kernelci.org/c/stable/linux-6.6.y/5fa4793a2d2d70ad08b85387b41020f… giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git branch: linux-6.6.y commit hash: 5fa4793a2d2d70ad08b85387b41020f1fcc2d19e origin: maestro test start time: 2025-12-06 22:05:24.119000+00:00 Builds: 35 ✅ 4 ❌ 0 ⚠️ Boots: 92 ✅ 0 ❌ 0 ⚠️ Tests: 4404 ✅ 350 ❌ 1689 ⚠️ ### POSSIBLE REGRESSIONS No possible regressions observed. ### FIXED REGRESSIONS Hardware: beaglebone-black > Config: multi_v7_defconfig - Architecture/compiler: arm/gcc-14 - ltp last run: https://d.kernelci.org/test/maestro:6934b2071ca5bf9d0fd63f8f history: > ❌ > ❌ > ❌ > ✅ > ✅ ### UNSTABLE TESTS No unstable tests observed. This branch has 4 pre-existing build issues. See details in the dashboard. Sent every day if there were changes in the past 24 hours. Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE -- 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

2 days, 4 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror