On Thu, Jan 04, 2024 at 03:07:18PM -0500, Andy Gospodarek wrote:
> On Wed, Jan 03, 2024 at 11:04:11AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 02, 2024 at 10:22:02AM -0500, Andy Gospodarek wrote:
> > > On Sat, Dec 30, 2023 at 11:58:29AM +0000, Greg Kroah-Hartman wrote:
> > > > 6.6-stable review patch. If anyone has any objections, please let me know.
> > > >
> > >
> > > No objections from me.
> > >
> > > For reference I do have an implementation of this functionality to v6.1
> > > if/when it should be added. It is different as the bnxt_en driver did
> > > not use the page pool to manage DMA mapping until v6.6.
> > >
> > > The minimally disruptive patch to prevent this memory leak is below:
> > >
> > > >From dc82f8b57e2692ec987628b53e6446ab9f4fa615 Mon Sep 17 00:00:00 2001
> > > From: Andy Gospodarek <andrew.gospodarek@xxxxxxxxxxxx>
> > > Date: Thu, 7 Dec 2023 16:23:21 -0500
> > > Subject: [PATCH] bnxt_en: unmap frag buffers before returning page to pool
> > >
> > > If pages are not unmapped before calling page_pool_recycle_direct they
> > > will not be freed back to the pool. This will lead to a memory leak and
> > > messages like the following in dmesg:
> > >
> > > [ 8229.436920] page_pool_release_retry() stalled pool shutdown 340 inflight 5437 sec
> > >
> > > Fixes: a7559bc8c17c ("bnxt: support transmit and free of aggregation buffers")
> > > Signed-off-by: Andy Gospodarek <andrew.gospodarek@xxxxxxxxxxxx>
> > > ---
> > > drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> >
> > I do not understand, what is this patch for?
> >
> > Why not submit it for normal inclusion first?
>
> Greg,
>
> I wondered if my description was good enough -- it was not. :)
>
> The sole purpose for sending my last email was to let you know that this
> problem also occurs on v6.1 but in a different manner.
>
> In the process of fixing this problem on the tip of tree I noted it was also an
> issue on older kernels, so that was why I brought it up.
>
> This is a bit confusing as the Fixes: tag was correctly set to changes that
> were made for v6.6 as it was the first kernel where this type of leak was
> noted.
>
> Hopefully that resolves the confusion.
Nope, sorry, I still have no idea what to do with this change at all.
It's not submitted as a "normal" change so what should be done with it?
confused,
greg k-h
