[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180802061229.vg4zefomfxek4vvi@mwanda>
Date: Thu, 2 Aug 2018 09:12:29 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Jheng-Jhong Wu <goodwater.wu@...il.com>
Cc: devel@...verdev.osuosl.org, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: mt29f_spinand: fix memory leak while
programming pages
On Thu, Aug 02, 2018 at 11:42:30AM +0800, Jheng-Jhong Wu wrote:
> Dear Dan,
>
> I know what you wrote, but before the spinand device is removed and
> freed memory automatically, programming pages may do many many times.
> Assume we erase and rewrite a large part of the flash, then
> spinand_program_page() might exhaust memory if memory is not large
> enough.
> In fact, OOM indeed occured when I tested programming multi-pages by
> mtd_debug tool.
> If OOM was not caused by devm_kzalloc() in spinand_program_page(),
> what may exhaust memory?
>
Ok. That makes sense. I didn't look at it in context. You should say
that sort of thing in your changelog. Looking at it now, the devm_
model isn't right for this function so we should change it to use normal
kzalloc().
We should fix all the error paths as well. It looks like if this
function starts returning errors, we are probably toasted, but it's
still good practice to avoid slow leaks.
regards,
dan carpenter
Powered by blists - more mailing lists