linux-kernel - Re: [PATCH v2 1/4] mm/zswap: bugfix: memory leak when re-swapon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 9 Sep 2013 12:03:49 -0500
From:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
To:	Weijie Yang <weijie.yang@...sung.com>
Cc:	minchan@...nel.org, bob.liu@...cle.com, weijie.yang.kh@...il.com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] mm/zswap: bugfix: memory leak when re-swapon

On Fri, Sep 06, 2013 at 01:16:45PM +0800, Weijie Yang wrote:
> zswap_tree is not freed when swapoff, and it got re-kmalloc in swapon,
> so memory-leak occurs.
> 
> Modify: free memory of zswap_tree in zswap_frontswap_invalidate_area().
> 
> Signed-off-by: Weijie Yang <weijie.yang@...sung.com>
> ---
>  mm/zswap.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mm/zswap.c b/mm/zswap.c
> index deda2b6..cbd9578 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -816,6 +816,10 @@ static void zswap_frontswap_invalidate_area(unsigned type)
>  	}
>  	tree->rbroot = RB_ROOT;
>  	spin_unlock(&tree->lock);
> +
> +	zbud_destroy_pool(tree->pool);
> +	kfree(tree);
> +	zswap_trees[type] = NULL;

You changed how this works from v1.  Any particular reason?

In this version you free the tree structure, which is fine as long as we
know for sure nothing will try to access it afterward unless there is a
swapon to reactivate it.

I'm just a little worried about a race here between a store and
invalidate_area.  I think there is probably some mechanism to prevent
this, I just haven't been able to demonstrate it to myself.

The situation I'm worried about is:

shrink_page_list()
add_to_swap() then return (gets the swap entry)
try_to_unmap() then return (sets the swap entry in the pte)
pageout()
swap_writepage()
zswap_frontswap_store()

interacting with a swapoff operation.

When zswap_frontswap_store() is called, we continue to hold the page
lock.  I think that might block the loop in try_to_unuse(), called by
swapoff, until we release it after the store.

I think it should be fine.  Just wanted to think it through.

Acked-by: Seth Jennings <sjenning@...ux.vnet.ibm.com>

>  }
> 
>  static struct zbud_ops zswap_zbud_ops = {
> -- 
> 1.7.10.4
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/