[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190826051340.GA26785@jagdpanzerIV>
Date: Mon, 26 Aug 2019 14:13:40 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Henry Burns <henrywolfeburns@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Henry Burns <henryburns@...gle.com>,
Minchan Kim <minchan@...nel.org>,
Nitin Gupta <ngupta@...are.org>,
Shakeel Butt <shakeelb@...gle.com>,
Jonathan Adams <jwadams@...gle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2 v2] mm/zsmalloc.c: Fix race condition in
zs_destroy_pool
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 page. I don't know what a -stable
> backport entails, but this crash would only occur if people are
> changing their zswap backend at runtime
> (which eventually starts destruction).
Well, zram/zsmalloc is not only for swapping, but it's also a virtual
block device which can be created or destroyed dynamically. So it looks
like a potential -stable material.
Minchan?
-ss
Powered by blists - more mailing lists