linux-kernel - Re: [BUGFIX][PATCH] memcg: ensure list is empty at rmdir

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 13 Jan 2010 12:27:54 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Daisuke Nishimura <nishimura@....nes.nec.co.jp>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>, stable <stable@...nel.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: [BUGFIX][PATCH] memcg: ensure list is empty at rmdir

On Wed, 13 Jan 2010 10:30:06 +0900
Daisuke Nishimura <nishimura@....nes.nec.co.jp> wrote:
> This patch tries to fix this bug by ensuring not only the usage is zero but also
> all of the LRUs are empty. mem_cgroup_force_empty_list() checks the list is empty
> or not, so we can make use of it.
>

Hmm, too short ? ;) fix me if following is wrong.

 Logical Background.
 
 The problem here is pages on LRU may contain pointer to stale memcg. To make
 res->usage to be 0, all pages on memcg must be uncharged. Uncharge page_cgroup
 contains pointer to memcg withou PCG_USED bit. (This asynchronous LRU work is
 for improving performance.) If PCG_USED bit is not set, page_cgroup will never
 be added to memcg's LRU. So, about pages not on LRU, they never access stale
 pointer. Then, what we have to take care of is page_cgroup _on_ LRU list.
 
 Before this patch, mem->res.usage is checked after lru_add_drain(). But this
 doesn't guarantee memcg's LRU is really empty (considering races with other cpus.)
 In usual workload, in most case, current logic works without bug. (Considering
 how rmdir->force_empty() works..). But in some heavy workload case, pages remain
 on LRU can cause invalid access to freed memcg. This patch fixes rmdir->force_empty
 to visit all all LRUs before exiting this force_empty loop and guarantee there
 are no pages on memcg's LRU.


Thanks,
-Kame

 
> Signed-off-by: Daisuke Nishimura <nishimura@....nes.nec.co.jp>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
> Cc: Balbir Singh <balbir@...ux.vnet.ibm.com>
> Cc: stable@...nel.org
> ---
> This patch is based on 2.6.33-rc3, and can be applied to older versions too.
> 
>  mm/memcontrol.c |   11 ++++-------
>  1 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 488b644..954032b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2586,7 +2586,7 @@ static int mem_cgroup_force_empty(struct mem_cgroup *mem, bool free_all)
>  	if (free_all)
>  		goto try_to_free;
>  move_account:
> -	while (mem->res.usage > 0) {
> +	do {
>  		ret = -EBUSY;
>  		if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children))
>  			goto out;
> @@ -2614,8 +2614,8 @@ move_account:
>  		if (ret == -ENOMEM)
>  			goto try_to_free;
>  		cond_resched();
> -	}
> -	ret = 0;
> +	/* "ret" should also be checked to ensure all lists are empty. */
> +	} while (mem->res.usage > 0 || ret);
>  out:
>  	css_put(&mem->css);
>  	return ret;
> @@ -2648,10 +2648,7 @@ try_to_free:
>  	}
>  	lru_add_drain();
>  	/* try move_account...there may be some *locked* pages. */
> -	if (mem->res.usage)
> -		goto move_account;
> -	ret = 0;
> -	goto out;
> +	goto move_account;
>  }
>  
>  int mem_cgroup_force_empty_write(struct cgroup *cont, unsigned int event)
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
> 

--
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/