From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Priyank Rathod <rathodpriyank@google.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver O'Halloran <oohall@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: Lukas Wunner <lukas@wunner.de>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v4 0/2] PCI/AER: Fix ghes_estatus_pool memory leaks in error handling
Date: Fri, 25 Sep 2026 11:24:53 -0700 [thread overview]
Message-ID: <4513e7d4-4e2f-42d8-8f0c-2f0e03815dee@linux.intel.com> (raw)
In-Reply-To: <20260918-b4-fix-aer-memleaks-v4-0-f0a2c21ed1d1@google.com>
Hi,
On 9/18/2026 10:24 AM, Priyank Rathod wrote:
> When firmware reports PCIe Advanced Error Reporting (AER) events via ACPI
> APEI GHES (ghes_handle_aer()), it allocates a snapshot buffer from
> ghes_estatus_pool to store the aer_capability_regs registers before
> enqueuing the error record into aer_recover_ring.
>
> aer_recover_queue() returns void, so ghes_handle_aer() cannot release that
> buffer itself; ownership is handed to the AER code, which until now freed
> it only on the fully successful path. If the record cannot be enqueued, or
> if a dequeued record cannot be mapped to a pci_dev, the allocation is
> silently leaked. Under a sustained error storm this exhausts
> ghes_estatus_pool, which then breaks GHES hardware error reporting
> system-wide.
>
> This series fixes both leak paths:
>
> Patch 1: aer_recover_queue() when kfifo_in_spinlocked() fails because
> aer_recover_ring (capacity 16) is full. The rejected entry is
> freed immediately via ghes_estatus_pool_region_free().
>
> Patch 2: aer_recover_work_func() when a dequeued entry cannot be mapped to
> an active PCI device (pdev is NULL). The loop is restructured so
> ghes_estatus_pool_region_free() runs unconditionally for every
> dequeued item.
>
> Signed-off-by: Priyank Rathod <rathodpriyank@google.com>
> ---
I'm fine with the current approach. aer_recover_work_func() already
owns and frees the buffer, so freeing it on the enqueue failure path
keeps the ownership in one place, and it keeps the stable backport
minimal. It might be worth adding a kernel-doc comment on
aer_recover_queue() stating that it takes ownership of @aer_regs,
which must be allocated from ghes_estatus_pool, so future callers
don't trip over it.
For the series:
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Changes in v4:
> - Rebased onto v7.3-rc3+ (f259f446f519); applies cleanly to pci/next as
> well. No conflicts with the Advisory Non-Fatal Error support that landed
> in the meantime.
> - Added missing Fixes: e2abc47a5a1a ("ACPI: APEI: Fix AER info corruption
> when error status data has multiple sections") and Cc: stable to both
> patches; that commit (v6.7-rc1) introduced the ghes_estatus_pool
> allocation whose ownership these paths drop.
> - Patch 1: use braces on both arms of the if/else and fix the continuation
> alignment (checkpatch --strict).
> - Both patches now build warning-free with W=1 and CONFIG_ACPI_APEI_PCIEAER=y
> (earlier revisions were only build-tested with APEI disabled, which
> compiles neither of the modified functions).
> - Explained in both commit messages why the caller cannot free the buffer,
> and when the missing-pci_dev path is reachable.
> - Cc: Lukas Wunner, who has been active in this code.
> - Link to v3: https://lore.kernel.org/r/20260803-b4-fix-aer-memleaks-v3-1-e87159611933@google.com
>
> Changes in v3:
> - Resent to fix threading of the series.
> - Link to v2: https://lore.kernel.org/r/20260803-b4-fix-aer-memleaks-v2-1-fd199b0171fd@google.com
>
> Changes in v2:
> - Refactored aer_recover_work_func() to ensure ghes_estatus_pool_region_free()
> is called unconditionally for every dequeued record.
> - Added Patch 1 to fix related memory leak in aer_recover_queue() on kfifo
> buffer overflow.
> - Link to v1: https://lore.kernel.org/r/20260803183853.432459-2-rathodpriyank@google.com
>
> ---
> Priyank Rathod (2):
> PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow
> PCI/AER: Fix memory leak in aer_recover_work_func() when pci_dev is missing
>
> drivers/pci/pcie/aer.c | 30 +++++++++++++++++-------------
> 1 file changed, 17 insertions(+), 13 deletions(-)
> ---
> base-commit: f259f446f5198d98e13756d2cd531812a0ad3064
> change-id: 20260803-b4-fix-aer-memleaks-524a1bd5e888
>
> Best regards,
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
prev parent reply other threads:[~2026-09-25 18:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 17:24 Priyank Rathod
2026-09-18 17:24 ` [PATCH v4 1/2] PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow Priyank Rathod
2026-09-18 17:25 ` [PATCH v4 2/2] PCI/AER: Fix memory leak in aer_recover_work_func() when pci_dev is missing Priyank Rathod
2026-09-18 18:15 ` [PATCH v4 0/2] PCI/AER: Fix ghes_estatus_pool memory leaks in error handling Priyank Rathod
2026-09-25 18:24 ` Kuppuswamy Sathyanarayanan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4513e7d4-4e2f-42d8-8f0c-2f0e03815dee@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lukas@wunner.de \
--cc=mahesh@linux.ibm.com \
--cc=oohall@gmail.com \
--cc=rathodpriyank@google.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®