linux-kernel - linux-next: manual merge of the akpm tree with the cgroup tree

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>] [day] [month] [year] [list]

Date:	Tue, 6 Nov 2012 15:51:28 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Glauber Costa <glommer@...allels.com>,
	Michal Hocko <mhocko@...e.cz>, Tejun Heo <tj@...nel.org>
Subject: linux-next: manual merge of the akpm tree with the cgroup tree

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/memcontrol.c between commit ab5196c202c6 ("memcg: make
mem_cgroup_reparent_charges non failing") from the cgroup tree and commit
"memcg: allow a memcg with kmem charges to be destructed" from the akpm
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

diff --cc mm/memcontrol.c
index 8f2b789,540bac5..0000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -3987,11 -4015,15 +3992,12 @@@ static void mem_cgroup_force_empty_list
   *
   * Caller is responsible for holding css reference on the memcg.
   */
 -static int mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
 +static void mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
  {
 -	struct cgroup *cgrp = memcg->css.cgroup;
  	int node, zid;
+ 	u64 usage;
  
  	do {
 -		if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children))
 -			return -EBUSY;
  		/* This is for making all *used* pages to be on LRU. */
  		lru_add_drain_all();
  		drain_all_stock_sync(memcg);
@@@ -4016,7 -4053,11 +4027,9 @@@
  		 * right after the check. RES_USAGE should be safe as we always
  		 * charge before adding to the LRU.
  		 */
- 	} while (res_counter_read_u64(&memcg->res, RES_USAGE) > 0);
+ 		usage = res_counter_read_u64(&memcg->res, RES_USAGE) -
+ 			res_counter_read_u64(&memcg->kmem, RES_USAGE);
+ 	} while (usage > 0);
 -
 -	return 0;
  }
  
  /*

Content of type "application/pgp-signature" skipped