linux-kernel - Re: 3.13-rc breaks MEMCG

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, 16 Dec 2013 18:19:37 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	Tejun Heo <tj@...nel.org>
Cc:	Li Zefan <lizefan@...wei.com>, Hugh Dickins <hughd@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm@...ck.org, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: 3.13-rc breaks MEMCG_SWAP

On Mon 16-12-13 11:35:30, Tejun Heo wrote:
> On Mon, Dec 16, 2013 at 11:40:42AM +0100, Michal Hocko wrote:
> > > How would this work? The task which pushed the memory to the swap is
> > > still alive (living in a different group) and the swap will be there
> > > after the last reference to css as well.
> > 
> > Or did you mean to get css reference in swap_cgroup_record and release
> > it in __mem_cgroup_try_charge_swapin?
> > 
> > That would prevent the warning (assuming idr_remove would move to
> > css_free[1]) but I am not sure this is the right thing to do. memsw charges
> > will be accounted to the parent already (assuming there is one) without
> > anybody to uncharge them because all uncharges would fallback to the
> > root memcg after css_offline.
> > 
> > Hugh's approach seems much better.
> 
> Hmmm... I think it's reasonable for css's to expect cgrp->id to not be
> recycled before all css refs are gone.  If Hugh's patches are
> something desriable independent of cgrp->id issues, great, but, if
> not, let's first try to get it right from cgroup core.  Is it enough
> for css_from_id() to return NULL after offline until all refs are
> gone?  That should be an easy fix.

I have to think about it some more (the brain is not working anymore
today). But what we really need is that nobody gets the same id while
the css is alive. So css_from_id returning NULL doesn't seem to be
enough.

-- 
Michal Hocko
SUSE Labs
--
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/