All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Shiju Jose" <shiju.jose@huawei.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/3] PCI/AER: Document that aer_recover_queue() takes ownership of aer_regs
Date: Tue, 6 Oct 2026 10:13:21 -0700	[thread overview]
Message-ID: <eec2107f-2c08-44ad-98c8-2c92f7a31fd3@linux.intel.com> (raw)
In-Reply-To: <20260928-b4-fix-aer-memleaks-v5-3-ba6b94c9c9a6@google.com>

Hi,

On 9/28/2026 10:40 AM, Priyank Rathod wrote:
> ghes_handle_aer() allocates the AER register snapshot that it passes to
> aer_recover_queue() from ghes_estatus_pool.  aer_recover_queue() returns
> void, so the caller cannot tell whether the record was queued, and the
> AER code owns the buffer from then on and must free it on every path.
> 
> None of this is documented at the definition of this exported function.
> With GHES enabled, a new caller that passed a buffer from any other
> allocator would hit the BUG() in gen_pool_free_owner() when the AER code
> returns the buffer to ghes_estatus_pool, and a caller that freed the
> buffer itself would cause a double free.
> 
> Add a kernel-doc comment that describes the parameters and states that
> aer_recover_queue() takes ownership of @aer_regs, which must have been
> allocated from ghes_estatus_pool.
> 
> No functional change.
> 

Thanks, this matches what I had in mind. 

Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>

Bjorn, I see you already applied the series to pci/aer. Feel free to
pick up the tag if it is still convenient.

> Suggested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Link: https://lore.kernel.org/r/4513e7d4-4e2f-42d8-8f0c-2f0e03815dee@linux.intel.com
> Signed-off-by: Priyank Rathod <rathodpriyank@google.com>
> ---
>  drivers/pci/pcie/aer.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index a6600801af6e..a58244e00bc4 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1404,6 +1404,24 @@ static void aer_recover_work_func(struct work_struct *work)
>  static DEFINE_SPINLOCK(aer_recover_ring_lock);
>  static DECLARE_WORK(aer_recover_work, aer_recover_work_func);
>  
> +/**
> + * aer_recover_queue - queue an AER error record reported by firmware
> + * @domain: PCI domain (segment) of the device that reported the error
> + * @bus: bus number of the device that reported the error
> + * @devfn: encoded device and function number, as returned by PCI_DEVFN()
> + * @severity: AER_CORRECTABLE, AER_NONFATAL or AER_FATAL
> + * @aer_regs: snapshot of the device's AER Capability registers
> + *
> + * Queue an error record received from firmware through APEI GHES.  The
> + * record is processed later from a workqueue, which logs the error and,
> + * for uncorrectable errors, attempts recovery of the device.
> + *
> + * Takes ownership of @aer_regs, which must have been allocated from
> + * ghes_estatus_pool with a size of sizeof(struct aer_capability_regs).
> + * The buffer is freed with ghes_estatus_pool_region_free() by the work
> + * item that processes the record, or immediately if the queue is full.
> + * The caller must not access or free @aer_regs after this call.
> + */
>  void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
>  		       int severity, struct aer_capability_regs *aer_regs)
>  {
> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer


  parent reply	other threads:[~2026-10-06 17:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 17:40 [PATCH v5 0/3] PCI/AER: Fix ghes_estatus_pool memory leaks in error handling Priyank Rathod
2026-09-28 17:40 ` [PATCH v5 1/3] PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow Priyank Rathod
2026-09-28 17:46   ` sashiko-bot
2026-09-28 17:40 ` [PATCH v5 2/3] PCI/AER: Fix memory leak in aer_recover_work_func() when pci_dev is missing Priyank Rathod
2026-09-28 17:46   ` sashiko-bot
2026-09-28 17:40 ` [PATCH v5 3/3] PCI/AER: Document that aer_recover_queue() takes ownership of aer_regs Priyank Rathod
2026-09-28 17:44   ` sashiko-bot
2026-10-06 17:13   ` Kuppuswamy Sathyanarayanan [this message]
2026-10-05 15:45 ` [PATCH v5 0/3] PCI/AER: Fix ghes_estatus_pool memory leaks in error handling Priyank Rathod
2026-10-05 23:27 ` Bjorn Helgaas

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=eec2107f-2c08-44ad-98c8-2c92f7a31fd3@linux.intel.com \
    --to=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=dave.jiang@intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jic23@kernel.org \
    --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=rafael.j.wysocki@intel.com \
    --cc=rathodpriyank@google.com \
    --cc=shiju.jose@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.