On Tue, Sep 24, 2013 at 9:11 AM, Minchan Kim <minchan@xxxxxxxxxx> wrote: > On Mon, Sep 23, 2013 at 04:19:36PM +0800, Weijie Yang wrote: >> This patch series fix a few bugs in mm/zswap based on Linux-3.11. >> >> v2 --> v3 >> - keep GFP_KERNEL flag > > Why do you drop this? > > It's plain BUG. I read Bob's reply but it couldn't justify to let the pain > remain. First of all, let's fix it and better idea could come later. Hi, Minchan. Thanks for review What I thought is that better idea could come sooner if I keep this flag rather than fixing it Yes, you are right. Fixing a bug has a higher priority than waiting for better idea. I will add it again in the next version patch set. >> >> v1 --> v2 >> - free memory in zswap_frontswap_invalidate_area(in patch 1) >> - fix whitespace corruption (line wrapping) >> >> Corresponding mail thread: https://lkml.org/lkml/2013/8/18/59 >> >> These issues fixed/optimized are: >> >> 1. memory leaks when re-swapon >> >> 2. memory leaks when invalidate and reclaim occur concurrently >> >> 3. avoid unnecessary page scanning >> >> >> Issues discussed in that mail thread NOT fixed as it happens rarely or >> not a big problem or controversial: >> >> 1. a "theoretical race condition" when reclaim page >> When a handle alloced from zbud, zbud considers this handle is used >> validly by upper(zswap) and can be a candidate for reclaim. But zswap has >> to initialize it such as setting swapentry and adding it to rbtree. >> so there is a race condition, such as: >> thread 0: obtain handle x from zbud_alloc >> thread 1: zbud_reclaim_page is called >> thread 1: callback zswap_writeback_entry to reclaim handle x >> thread 1: get swpentry from handle x (it is random value now) >> thread 1: bad thing may happen >> thread 0: initialize handle x with swapentry >> >> 2. frontswap_map bitmap not cleared after zswap reclaim >> Frontswap uses frontswap_map bitmap to track page in "backend" implementation, >> when zswap reclaim a page, the corresponding bitmap record is not cleared. >> >> 3. the potential that zswap store and reclaim functions called recursively >> >> >> mm/zswap.c | 28 ++++++++++++++++++++-------- >> 1 file changed, 20 insertions(+), 8 deletions(-) >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majordomo@xxxxxxxxx. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> > > -- > Kind regards, > Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html