[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5757d0ff5754f537b16ae36f9e7b5c2399c2cb5e.camel@maquefel.me>
Date: Wed, 29 May 2024 12:34:02 +0300
From: Nikita Shubin <nikita.shubin@...uefel.me>
To: Dave Jiang <dave.jiang@...el.com>, n.shubin@...ro.com, Vinod Koul
<vkoul@...nel.org>, Logan Gunthorpe <logang@...tatee.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>, dmaengine@...r.kernel.org,
linux-kernel@...r.kernel.org, linux@...ro.com
Subject: Re: [PATCH v2 0/3] dmaengine: ioatdma: Fix mem leakage series
Hello Dave!
On Tue, 2024-05-28 at 09:08 -0700, Dave Jiang wrote:
>
>
> On 5/27/24 11:09 PM, Nikita Shubin via B4 Relay wrote:
> > Started with observing leakage in patch 3, investigating revealed
> > much
> > more problems in probing error path.
> >
> > Andy you are always welcome to review if you have a spare time.
> >
> > Thank you Andy and Markus for your comments.
> >
> > Signed-off-by: Nikita Shubin <n.shubin@...ro.com>
> > ---
> > Changes in v2:
> > - dmaengine: ioatdma: Fix error path in ioat3_dma_probe():
> > Markus:
> > - fix typo
> >
> > - dmaengine: ioatdma: Fix kmemleak in ioat_pci_probe()
> > Andy:
> > - s/int/unsigned int/
> > - fix spelling errors
> > - trimmed kmemleak reports
> >
> > - Link to v1:
> > https://lore.kernel.org/r/20240524-ioatdma-fixes-v1-0-b785f1f7accc@yadro.com
> >
> > ---
> > Nikita Shubin (3):
> > dmaengine: ioatdma: Fix leaking on version mismatch
> > dmaengine: ioatdma: Fix error path in ioat3_dma_probe()
> > dmaengine: ioatdma: Fix kmemleak in ioat_pci_probe()
> >
> > drivers/dma/ioat/init.c | 54 ++++++++++++++++++++++++++-----------
> > ------------
> > 1 file changed, 29 insertions(+), 25 deletions(-)
> > ---
> > base-commit: 6d69b6c12fce479fde7bc06f686212451688a102
> > change-id: 20240524-ioatdma-fixes-a8fccda9bd79
>
> Thanks for the fixes.
Glad i could help.
You might find this one useful:
https://patchwork.ozlabs.org/project/qemu-devel/patch/20240524114547.28801-1-nikita.shubin@maquefel.me/
I think sometimes it's much more faster to test something with QEMU
than tinkering with real hardware.
>
> Reviewed-by: Dave Jiang <dave.jiang@...el.com> for the series
>
> Would be nice if someone wants to move everything to the devm_*
> management APIs. Would make this a lot less messy. Probably not worth
> the effort though given how old the driver is and no more devices are
> being created to use this driver.
>
> >
> > Best regards,
Powered by blists - more mailing lists