Re: [PATCH 6.6 055/156] bnxt_en: do not map packet buffers twice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-andy






[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux