On (08/23/19 04:10), Henry Burns wrote:
> > Thanks. So we have a couple of races which result in memory leaks? Do
> > we feel this is serious enough to justify a -stable backport of the
> > fixes?
>
> In this case a memory leak could lead to an eventual crash if
> compaction hits the leaked
On Thu, Aug 22, 2019 at 7:23 PM Andrew Morton wrote:
>
> On Tue, 20 Aug 2019 11:59:39 +0900 Sergey Senozhatsky
> wrote:
>
> > On (08/09/19 11:17), Henry Burns wrote:
> > > In zs_destroy_pool() we call flush_work(>free_work). However, we
> > > have no guarantee that migration isn't happening in
On Tue, 20 Aug 2019 11:59:39 +0900 Sergey Senozhatsky
wrote:
> On (08/09/19 11:17), Henry Burns wrote:
> > In zs_destroy_pool() we call flush_work(>free_work). However, we
> > have no guarantee that migration isn't happening in the background
> > at that time.
> >
> > Since migration can't
On (08/09/19 11:17), Henry Burns wrote:
> In zs_destroy_pool() we call flush_work(>free_work). However, we
> have no guarantee that migration isn't happening in the background
> at that time.
>
> Since migration can't directly free pages, it relies on free_work
> being scheduled to free the
In zs_destroy_pool() we call flush_work(>free_work). However, we
have no guarantee that migration isn't happening in the background
at that time.
Since migration can't directly free pages, it relies on free_work
being scheduled to free the pages. But there's nothing preventing an
in-progress
5 matches
Mail list logo
