September 2025 - Linux-stable-mirror

[PATCH] ASoC: mediatek: mt8365: Add check for devm_kcalloc() in mt8365_afe_suspend()

by Guangshuo Li

devm_kcalloc() may fail. mt8365_afe_suspend() uses afe->reg_back_up unconditionally after allocation and writes afe->reg_back_up[i], which can lead to a NULL pointer dereference under low-memory conditions. Add a NULL check and bail out with -ENOMEM, making sure to disable the main clock via the existing error path to keep clock state balanced. Fixes: e1991d102bc2 ("ASoC: mediatek: mt8365: Add the AFE driver support") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- sound/soc/mediatek/mt8365/mt8365-afe-pcm.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c index 10793bbe9275..9f398d1249ce 100644 --- a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c +++ b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c @@ -1971,22 +1971,26 @@ static int mt8365_afe_suspend(struct device *dev) { struct mtk_base_afe *afe = dev_get_drvdata(dev); struct regmap *regmap = afe->regmap; - int i; + int i, ret = 0; mt8365_afe_enable_main_clk(afe); - if (!afe->reg_back_up) - afe->reg_back_up = - devm_kcalloc(dev, afe->reg_back_up_list_num, - sizeof(unsigned int), GFP_KERNEL); + if (!afe->reg_back_up) { + afe->reg_back_up = devm_kcalloc(dev, afe->reg_back_up_list_num, + sizeof(unsigned int), GFP_KERNEL); + if (!afe->reg_back_up) { + ret = -ENOMEM; + goto out_disable_clk; + } + } for (i = 0; i < afe->reg_back_up_list_num; i++) regmap_read(regmap, afe->reg_back_up_list[i], &afe->reg_back_up[i]); - +out_disable_clk: mt8365_afe_disable_main_clk(afe); - return 0; + return ret; } static int mt8365_afe_resume(struct device *dev) -- 2.43.0

3 days, 7 hours

2
1
0 0

[PATCH] iommu/amd/pgtbl: Fix possible race while increase page table level

by Vasant Hegde

The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path. Reported-by: Alejandro Jimenez <alejandro.j.jimenez(a)oracle.com> Cc: stable(a)vger.kernel.org Cc: Joao Martins <joao.m.martins(a)oracle.com> Cc: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> Signed-off-by: Vasant Hegde <vasant.hegde(a)amd.com> --- drivers/iommu/amd/amd_iommu_types.h | 1 + drivers/iommu/amd/io_pgtable.c | 25 +++++++++++++++++++++---- 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h index 5219d7ddfdaa..95f63c5f6159 100644 --- a/drivers/iommu/amd/amd_iommu_types.h +++ b/drivers/iommu/amd/amd_iommu_types.h @@ -555,6 +555,7 @@ struct gcr3_tbl_info { }; struct amd_io_pgtable { + seqcount_t seqcount; /* Protects root/mode update */ struct io_pgtable pgtbl; int mode; u64 *root; diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c index a91e71f981ef..70c2f5b1631b 100644 --- a/drivers/iommu/amd/io_pgtable.c +++ b/drivers/iommu/amd/io_pgtable.c @@ -17,6 +17,7 @@ #include <linux/slab.h> #include <linux/types.h> #include <linux/dma-mapping.h> +#include <linux/seqlock.h> #include <asm/barrier.h> @@ -130,8 +131,11 @@ static bool increase_address_space(struct amd_io_pgtable *pgtable, *pte = PM_LEVEL_PDE(pgtable->mode, iommu_virt_to_phys(pgtable->root)); + write_seqcount_begin(&pgtable->seqcount); pgtable->root = pte; pgtable->mode += 1; + write_seqcount_end(&pgtable->seqcount); + amd_iommu_update_and_flush_device_table(domain); pte = NULL; @@ -153,6 +157,7 @@ static u64 *alloc_pte(struct amd_io_pgtable *pgtable, { unsigned long last_addr = address + (page_size - 1); struct io_pgtable_cfg *cfg = &pgtable->pgtbl.cfg; + unsigned int seqcount; int level, end_lvl; u64 *pte, *page; @@ -170,8 +175,14 @@ static u64 *alloc_pte(struct amd_io_pgtable *pgtable, } - level = pgtable->mode - 1; - pte = &pgtable->root[PM_LEVEL_INDEX(level, address)]; + do { + seqcount = read_seqcount_begin(&pgtable->seqcount); + + level = pgtable->mode - 1; + pte = &pgtable->root[PM_LEVEL_INDEX(level, address)]; + } while (read_seqcount_retry(&pgtable->seqcount, seqcount)); + + address = PAGE_SIZE_ALIGN(address, page_size); end_lvl = PAGE_SIZE_LEVEL(page_size); @@ -249,6 +260,7 @@ static u64 *fetch_pte(struct amd_io_pgtable *pgtable, unsigned long *page_size) { int level; + unsigned int seqcount; u64 *pte; *page_size = 0; @@ -256,8 +268,12 @@ static u64 *fetch_pte(struct amd_io_pgtable *pgtable, if (address > PM_LEVEL_SIZE(pgtable->mode)) return NULL; - level = pgtable->mode - 1; - pte = &pgtable->root[PM_LEVEL_INDEX(level, address)]; + do { + seqcount = read_seqcount_begin(&pgtable->seqcount); + level = pgtable->mode - 1; + pte = &pgtable->root[PM_LEVEL_INDEX(level, address)]; + } while (read_seqcount_retry(&pgtable->seqcount, seqcount)); + *page_size = PTE_LEVEL_PAGE_SIZE(level); while (level > 0) { @@ -541,6 +557,7 @@ static struct io_pgtable *v1_alloc_pgtable(struct io_pgtable_cfg *cfg, void *coo if (!pgtable->root) return NULL; pgtable->mode = PAGE_MODE_3_LEVEL; + seqcount_init(&pgtable->seqcount); cfg->pgsize_bitmap = amd_iommu_pgsize_bitmap; cfg->ias = IOMMU_IN_ADDR_BIT_SIZE; -- 2.31.1

3 days, 7 hours

3
3
0 0

[PATCH] net: ethernet: broadcom: sb1250-mac: Add checks for kcalloc() in sbdma_initctx()

by Guangshuo Li

Two kcalloc() allocations (descriptor table and context table) can fail and are used unconditionally afterwards (ALIGN()/phys conversion and dereferences), leading to potential NULL pointer dereference. Check both allocations and bail out early; on the second failure, free the first allocation to avoid a leak. Do not emit extra OOM logs. Fixes: 73d739698017 ("sb1250-mac.c: De-typedef, de-volatile, de-etc...") Fixes: c477f3348abb ("drivers/net/sb1250-mac.c: kmalloc + memset conversion to kcalloc") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/net/ethernet/broadcom/sb1250-mac.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/broadcom/sb1250-mac.c b/drivers/net/ethernet/broadcom/sb1250-mac.c index 30865fe03eeb..e16a49e22488 100644 --- a/drivers/net/ethernet/broadcom/sb1250-mac.c +++ b/drivers/net/ethernet/broadcom/sb1250-mac.c @@ -625,6 +625,8 @@ static void sbdma_initctx(struct sbmacdma *d, struct sbmac_softc *s, int chan, d->sbdma_dscrtable_unaligned = kcalloc(d->sbdma_maxdescr + 1, sizeof(*d->sbdma_dscrtable), GFP_KERNEL); + if (!d->sbdma_dscrtable_unaligned) + return; /* avoid NULL deref in ALIGN/phys conversion */ /* * The descriptor table must be aligned to at least 16 bytes or the @@ -644,7 +646,11 @@ static void sbdma_initctx(struct sbmacdma *d, struct sbmac_softc *s, int chan, d->sbdma_ctxtable = kcalloc(d->sbdma_maxdescr, sizeof(*d->sbdma_ctxtable), GFP_KERNEL); - + if (!d->sbdma_ctxtable) { + kfree(d->sbdma_dscrtable_unaligned); + d->sbdma_dscrtable_unaligned = NULL; + return; + } #ifdef CONFIG_SBMAC_COALESCE /* * Setup Rx/Tx DMA coalescing defaults -- 2.43.0

3 days, 7 hours

2
1
0 0

[PATCH] ASoC: Intel: avs: Add check for kcalloc() when setting constraints

by Guangshuo Li

kcalloc() may fail. avs_path_set_constraint() writes to rlist[i], clist[i], and slist[i] unconditionally, which can cause a NULL pointer dereference under low-memory conditions. Add checks for the three kcalloc() calls. If any allocation fails, free any previously allocated lists and return -ENOMEM. Fixes: f2f847461fb7 ("ASoC: Intel: avs: Constrain path based on BE capabilities") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- sound/soc/intel/avs/path.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/intel/avs/path.c b/sound/soc/intel/avs/path.c index cafb8c6198be..cb641d37d565 100644 --- a/sound/soc/intel/avs/path.c +++ b/sound/soc/intel/avs/path.c @@ -135,6 +135,9 @@ int avs_path_set_constraint(struct avs_dev *adev, struct avs_tplg_path_template clist = kcalloc(i, sizeof(clist), GFP_KERNEL); slist = kcalloc(i, sizeof(slist), GFP_KERNEL); + if (!rlist || !clist || !slist) + return -ENOMEM; + i = 0; list_for_each_entry(path_template, &template->path_list, node) { struct avs_tplg_pipeline *pipeline_template; -- 2.43.0

3 days, 7 hours

2
1
0 0

[PATCH 0/2] PCI: Fix ACS enablement for Root Ports in DT platforms

by Manivannan Sadhasivam via B4 Relay

Hi, This series fixes the long standing issue with ACS in DT platforms. There are two fixes in this series, both fixing independent issues on their own, but both are needed to properly enable ACS on DT platforms (well, patch 1 is only needed for Juno board, but that was a blocker for patch 2, more below...). Issue(s) background =================== Back in 2024, Xingang Wang first noted a failure in attaching the HiSilicon SEC device to QEMU ARM64 pci-root-port device [1]. He then tracked down the issue to ACS not being enabled for the QEMU Root Port device and he proposed a patch to fix it [2]. Once the patch got applied, people reported PCIe issues with linux-next on the ARM Juno Development boards, where they saw failure in enumerating the endpoint devices [3][4]. So soon, the patch got dropped, but the actual issue with the ARM Juno boards was left behind. Fast forward to 2024, Pavan resubmitted the same fix [5] for his own usecase, hoping that someone in the community would fix the issue with ARM Juno boards. But the patch was rightly rejected, as a patch that was known to cause issues should not be merged to the kernel. But again, no one investigated the Juno issue and it was left behind again. Now it ended up in my plate and I managed to track down the issue with the help of Naresh who got access to the Juno boards in LKFT. The Juno issue is with the PCIe switch from Microsemi/IDT, which triggers ACS Source Validation error on Completions received for the Configuration Read Request from a device connected to the downstream port that has not yet captured the PCIe bus number. As per the PCIe spec r6.0 sec 2.2.6.2, "Functions must capture the Bus and Device Numbers supplied with all Type 0 Configuration Write Requests completed by the Function and supply these numbers in the Bus and Device Number fields of the Requester ID for all Requests". So during the first Configuration Read Request issued by the switch downstream port during enumeration (for reading Vendor ID), Bus and Device numbers will be unknown to the device. So it responds to the Read Request with Completion having Bus and Device number as 0. The switch interprets the Completion as an ACS Source Validation error and drops the completion, leading to the failure in detecting the endpoint device. Though the PCIe spec r6.0, sec 6.12.1.1, states that "Completions are never affected by ACS Source Validation". This behavior is in violation of the spec. This issue was already found and addressed with a quirk for a different device from Microsemi with 'commit, aa667c6408d2 ("PCI: Workaround IDT switch ACS Source Validation erratum")'. Apparently, this issue seems to be documented in the erratum #36 of IDT 89H32H8G3-YC, which is not publicly available. Solution for Juno issue ======================= To fix this issue, I've extended the quirk to the Device ID of the switch found in Juno R2 boards. I believe the same switch is also present in Juno R1 board as well. With Patch 1, the Juno R2 boards can now detect the endpoints even with ACS enabled for the Switch downstream ports. Finally, I added patch 2 that properly enables ACS for all the PCI devices on DT platforms. It should be noted that even without patch 2 which enables ACS for the Root Port, the Juno boards were failing since 'commit, bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")' as reported in LKFT [6]. I believe, this commit made sure pci_request_acs() gets called before the enumeration of the switch downstream ports. The LKFT team ended up disabling ACS using cmdline param 'pci=config_acs=000000@pci:0:0'. So I added the above mentioned commit as a Fixes tag for patch 1. Also, to mitigate this issue, one could enumerate all the PCIe devices in bootloader without enabling ACS (as also noted by Robin in the LKFT thread). This will make sure that the endpoint device has a valid bus number when it responds to the first Configuration Read Request from the switch downstream port. So the ACS Source Validation error doesn't get triggered. Solution for ACS issue ====================== To fix this issue, I've kept the patch from Xingang as is (with rewording of the patch subject/description). This patch moves the pci_request_acs() call to devm_of_pci_bridge_init(), which gets called during the host bridge registration. This makes sure that the 'pci_acs_enable' flag set by pci_request_acs() is getting set before the enumeration of the Root Port device. So now, ACS will be enabled for all ACS capable devices of DT platforms. [1] https://lore.kernel.org/all/038397a6-57e2-b6fc-6e1c-7c03b7be9d96@huawei.com [2] https://lore.kernel.org/all/1621566204-37456-1-git-send-email-wangxingang5@… [3] https://lore.kernel.org/all/01314d70-41e6-70f9-e496-84091948701a@samsung.com [4] https://lore.kernel.org/all/CADYN=9JWU3CMLzMEcD5MSQGnaLyDRSKc5SofBFHUax6YuT… [5] https://lore.kernel.org/linux-pci/20241107-pci_acs_fix-v1-1-185a2462a571@qu… [6] https://lists.linaro.org/archives/list/lkft-triage@lists.linaro.org/message… Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com> --- Manivannan Sadhasivam (1): PCI: Extend pci_idt_bus_quirk() for IDT switch with Device ID 0x8090 Xingang Wang (1): iommu/of: Call pci_request_acs() before enumerating the Root Port device drivers/iommu/of_iommu.c | 1 - drivers/pci/of.c | 8 +++++++- drivers/pci/probe.c | 2 +- 3 files changed, 8 insertions(+), 3 deletions(-) --- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250910-pci-acs-cb4fa3983a2c Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com>

3 days, 7 hours

3
4
0 0

[PATCH 0/3] drm/xe: Fix some rebar issues

by Lucas De Marchi

Our implementation for BAR2 (lmembar) resize works at the xe_vram layer and only releases that BAR before resizing. That is not always sufficient. If the parent bridge needs to move, the BAR0 also needs to be released, otherwise the resize fails. This is the case of not having enough space allocated from the beginning. Also, there's a BAR0 in the upstream port of the pcie switch in BMG preventing the resize to propagate to the bridge as previously discussed at https://lore.kernel.org/intel-xe/20250721173057.867829-1-uwu@icenowy.me/ and https://lore.kernel.org/intel-xe/wqukxnxni2dbpdhri3cbvlrzsefgdanesgskzmxi5s… I'm bringing that commit from Ilpo here so this can be tested with the xe changes and go to stable (first 2 patches). The third patch is just code move as all the logic is in a different layer now. That could wait longer though as there are other refactors coming through the PCI tree and that would conflict (see second link above). With this I could resize the lmembar on some problematic hosts and after doing an SBR, with one caveat: the audio device also prevents the BAR from moving and it needs to be manually removed before resizing. With the PCI refactors and BAR fitting logic that Ilpo is working on, it's expected that it won't be needed for a long time. Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- Ilpo Järvinen (1): PCI: Release BAR0 of an integrated bridge to allow GPU BAR resize Lucas De Marchi (2): drm/xe: Move rebar to be done earlier drm/xe: Move rebar to its own file drivers/gpu/drm/xe/Makefile | 1 + drivers/gpu/drm/xe/xe_pci.c | 3 + drivers/gpu/drm/xe/xe_pci_rebar.c | 125 ++++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/xe/xe_pci_rebar.h | 13 ++++ drivers/gpu/drm/xe/xe_vram.c | 103 ------------------------------- drivers/pci/quirks.c | 20 ++++++ 6 files changed, 162 insertions(+), 103 deletions(-) base-commit: 95bc43e85f952ef4ebfff1406883e1e07a7daeda change-id: 20250917-xe-pci-rebar-2-c0fe2f04c879 Lucas De Marchi

3 days, 7 hours

2
5
0 0

[PATCH v6] ACPI: battery: prevent sysfs_add_battery re-entry on rapid events

by GuangFei Luo

When removing and reinserting the laptop battery, ACPI can trigger two notifications in quick succession: - ACPI_BATTERY_NOTIFY_STATUS (0x80) - ACPI_BATTERY_NOTIFY_INFO (0x81) Both notifications call acpi_battery_update(). Because the events happen very close in time, sysfs_add_battery() can be re-entered before battery->bat is set, causing a duplicate sysfs entry error. When the ACPI battery driver uses acpi_dev_install_notify_handler() to register acpi_battery_notify, the callback may be triggered twice in a very short period of time. This patch ensures that sysfs_add_battery() is not re-entered when battery->bat is already non-NULL, preventing the duplicate sysfs creation and stabilizing battery hotplug handling. [ 476.117945] sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1' [ 476.118896] CPU: 1 UID: 0 PID: 185 Comm: kworker/1:4 Kdump: loaded Not tainted 6.12.38+deb13-amd64 #1 Debian 6.12.38-1 [ 476.118903] Hardware name: Gateway NV44 /SJV40-MV , BIOS V1.3121 04/08/2009 [ 476.118906] Workqueue: kacpi_notify acpi_os_execute_deferred [ 476.118917] Call Trace: [ 476.118922] <TASK> [ 476.118929] dump_stack_lvl+0x5d/0x80 [ 476.118938] sysfs_warn_dup.cold+0x17/0x23 [ 476.118943] sysfs_create_dir_ns+0xce/0xe0 [ 476.118952] kobject_add_internal+0xba/0x250 [ 476.118959] kobject_add+0x96/0xc0 [ 476.118964] ? get_device_parent+0xde/0x1e0 [ 476.118970] device_add+0xe2/0x870 [ 476.118975] __power_supply_register.part.0+0x20f/0x3f0 [ 476.118981] ? wake_up_q+0x4e/0x90 [ 476.118990] sysfs_add_battery+0xa4/0x1d0 [battery] [ 476.118998] acpi_battery_update+0x19e/0x290 [battery] [ 476.119002] acpi_battery_notify+0x50/0x120 [battery] [ 476.119006] acpi_ev_notify_dispatch+0x49/0x70 [ 476.119012] acpi_os_execute_deferred+0x1a/0x30 [ 476.119015] process_one_work+0x177/0x330 [ 476.119022] worker_thread+0x251/0x390 [ 476.119026] ? __pfx_worker_thread+0x10/0x10 [ 476.119030] kthread+0xd2/0x100 [ 476.119033] ? __pfx_kthread+0x10/0x10 [ 476.119035] ret_from_fork+0x34/0x50 [ 476.119040] ? __pfx_kthread+0x10/0x10 [ 476.119042] ret_from_fork_asm+0x1a/0x30 [ 476.119049] </TASK> [ 476.142552] kobject: kobject_add_internal failed for BAT1 with -EEXIST, don't try to register things with the same name in the same directory. [ 476.415022] ata1.00: unexpected _GTF length (8) [ 476.428076] sd 0:0:0:0: [sda] Starting disk [ 476.835035] ata1.00: unexpected _GTF length (8) [ 476.839720] ata1.00: configured for UDMA/133 [ 491.328831] sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1' [ 491.329720] CPU: 1 UID: 0 PID: 185 Comm: kworker/1:4 Kdump: loaded Not tainted 6.12.38+deb13-amd64 #1 Debian 6.12.38-1 [ 491.329727] Hardware name: Gateway NV44 /SJV40-MV , BIOS V1.3121 04/08/2009 [ 491.329731] Workqueue: kacpi_notify acpi_os_execute_deferred [ 491.329741] Call Trace: [ 491.329745] <TASK> [ 491.329751] dump_stack_lvl+0x5d/0x80 [ 491.329758] sysfs_warn_dup.cold+0x17/0x23 [ 491.329762] sysfs_create_dir_ns+0xce/0xe0 [ 491.329770] kobject_add_internal+0xba/0x250 [ 491.329775] kobject_add+0x96/0xc0 [ 491.329779] ? get_device_parent+0xde/0x1e0 [ 491.329784] device_add+0xe2/0x870 [ 491.329790] __power_supply_register.part.0+0x20f/0x3f0 [ 491.329797] sysfs_add_battery+0xa4/0x1d0 [battery] [ 491.329805] acpi_battery_update+0x19e/0x290 [battery] [ 491.329809] acpi_battery_notify+0x50/0x120 [battery] [ 491.329812] acpi_ev_notify_dispatch+0x49/0x70 [ 491.329817] acpi_os_execute_deferred+0x1a/0x30 [ 491.329820] process_one_work+0x177/0x330 [ 491.329826] worker_thread+0x251/0x390 [ 491.329830] ? __pfx_worker_thread+0x10/0x10 [ 491.329833] kthread+0xd2/0x100 [ 491.329836] ? __pfx_kthread+0x10/0x10 [ 491.329838] ret_from_fork+0x34/0x50 [ 491.329842] ? __pfx_kthread+0x10/0x10 [ 491.329844] ret_from_fork_asm+0x1a/0x30 [ 491.329850] </TASK> [ 491.329855] kobject: kobject_add_internal failed for BAT1 with -EEXIST, don't try to register things with the same name in the same directory. Fixes: 10666251554c ("ACPI: battery: Install Notify() handler directly") Signed-off-by: GuangFei Luo <luogf2025(a)163.com> Cc: stable(a)vger.kernel.org --- v6: - Update Fixes tag: point to commit 10666251554c ("ACPI: battery: Install Notify() handler directly"), which introduced the sysfs_add_battery() re-entry issue when acpi_battery_notify is registered via acpi_dev_install_notify_handler(). The problem does not occur with acpi_bus_register_driver(). v5: - Move changelog above the '---' line as per submission guidelines. v4: - Uses guard(mutex) for battery->sysfs_lock in sysfs_add_battery(). - Since sysfs_add_battery() now handles the battery->bat check with proper locking,the extra if (!battery->bat) check at the call site has become redundant. v3: - Modified the earlier approach: since sysfs_add_battery() is invoked from multiple places, the most reliable way is to add the lock inside the function itself. - sysfs_remove_battery() had a similar race issue in the past, which was fixed by adding a lock as well. Reference: https://lore.kernel.org/all/9c921c22a7f33397a6774d7fa076db9b6a0fd669 .1312318300.git.len.brown(a)intel.com/ v2: - Fix missing mutex_unlock in acpi_battery_update() (Reported-by: kernel test robot) v1: - Initial patch to handle race when hotplugging battery, preventing duplicate sysfs entries. --- drivers/acpi/battery.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 6905b56bf3e4..20d68f3e881f 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -850,6 +850,10 @@ static void __exit battery_hook_exit(void) static int sysfs_add_battery(struct acpi_battery *battery) { + guard(mutex)(&battery->sysfs_lock); + if (battery->bat) + return 0; + struct power_supply_config psy_cfg = { .drv_data = battery, .attr_grp = acpi_battery_groups, @@ -1026,11 +1030,9 @@ static int acpi_battery_update(struct acpi_battery *battery, bool resume) return result; acpi_battery_quirks(battery); - if (!battery->bat) { - result = sysfs_add_battery(battery); - if (result) - return result; - } + result = sysfs_add_battery(battery); + if (result) + return result; /* * Wakeup the system if battery is critical low @@ -1112,12 +1114,12 @@ static int battery_notify(struct notifier_block *nb, result = acpi_battery_get_info(battery); if (result) return result; - - result = sysfs_add_battery(battery); - if (result) - return result; } + result = sysfs_add_battery(battery); + if (result) + return result; + acpi_battery_init_alarm(battery); acpi_battery_get_state(battery); break; -- 2.43.0

3 days, 7 hours

1
0
0 0

[PATCH v2 1/7] mm: fix off-by-one error in VMA count limit checks

by Kalesh Singh

The VMA count limit check in do_mmap() and do_brk_flags() uses a strict inequality (>), which allows a process's VMA count to exceed the configured sysctl_max_map_count limit by one. A process with mm->map_count == sysctl_max_map_count will incorrectly pass this check and then exceed the limit upon allocation of a new VMA when its map_count is incremented. Other VMA allocation paths, such as split_vma(), already use the correct, inclusive (>=) comparison. Fix this bug by changing the comparison to be inclusive in do_mmap() and do_brk_flags(), bringing them in line with the correct behavior of other allocation paths. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: <stable(a)vger.kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: "Liam R. Howlett" <Liam.Howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Pedro Falcato <pfalcato(a)suse.de> Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> --- Chnages in v2: - Fix mmap check, per Pedro mm/mmap.c | 2 +- mm/vma.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index 7306253cc3b5..e5370e7fcd8f 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -374,7 +374,7 @@ unsigned long do_mmap(struct file *file, unsigned long addr, return -EOVERFLOW; /* Too many mappings? */ - if (mm->map_count > sysctl_max_map_count) + if (mm->map_count >= sysctl_max_map_count) return -ENOMEM; /* diff --git a/mm/vma.c b/mm/vma.c index 3b12c7579831..033a388bc4b1 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2772,7 +2772,7 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT)) return -ENOMEM; - if (mm->map_count > sysctl_max_map_count) + if (mm->map_count >= sysctl_max_map_count) return -ENOMEM; if (security_vm_enough_memory_mm(mm, len >> PAGE_SHIFT)) -- 2.51.0.384.g4c02a37b29-goog

3 days, 7 hours

7
8
0 0

[PATCH] drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()

by Guangshuo Li

kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Fixes: 6396bb221514 ("treewide: kzalloc() -> kcalloc()") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/gpu/drm/amd/amdgpu/atom.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c index 82a02f831951..bed3083f317b 100644 --- a/drivers/gpu/drm/amd/amdgpu/atom.c +++ b/drivers/gpu/drm/amd/amdgpu/atom.c @@ -1247,9 +1247,9 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index, if (ws) { ectx.ws = kcalloc(4, ws, GFP_KERNEL); if (!ectx.ws) { - ret = -ENOMEM; - goto free; - } + ret = -ENOMEM; + goto free; + } ectx.ws_size = ws; } else { ectx.ws = NULL; -- 2.43.0

3 days, 8 hours

2
1
0 0

[PATCH] drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()

by Guangshuo Li

kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Fixes: 6396bb221514 ("treewide: kzalloc() -> kcalloc()") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c index 81d195d366ce..bed3083f317b 100644 --- a/drivers/gpu/drm/amd/amdgpu/atom.c +++ b/drivers/gpu/drm/amd/amdgpu/atom.c @@ -1246,6 +1246,10 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index, ectx.last_jump_jiffies = 0; if (ws) { ectx.ws = kcalloc(4, ws, GFP_KERNEL); + if (!ectx.ws) { + ret = -ENOMEM; + goto free; + } ectx.ws_size = ws; } else { ectx.ws = NULL; -- 2.43.0

3 days, 8 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2025