linux-kernel - Re: [PATCH v3 4/7] memcg: remove memcg from the reclaim iterators

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]

Message-ID: <20130213103811.GC23562@dhcp22.suse.cz>
Date:	Wed, 13 Feb 2013 11:38:11 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	Glauber Costa <glommer@...allels.com>
Cc:	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Ying Han <yinghan@...gle.com>, Tejun Heo <htejun@...il.com>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [PATCH v3 4/7] memcg: remove memcg from the reclaim iterators

On Wed 13-02-13 12:11:59, Glauber Costa wrote:
> On 02/12/2013 09:37 PM, Johannes Weiner wrote:
> >> > All reads from root->dead_count are atomic already, so I am not sure
> >> > what you mean here. Anyway, I hope I won't make this even more confusing
> >> > if I post what I have right now:
> > Yes, but we are doing two reads.  Can't the memcg that we'll store in
> > last_visited be offlined during this and be freed after we drop the
> > rcu read lock?  If we had just one read, we would detect this
> > properly.
> > 
> 
> I don't want to add any more confusion to an already fun discussion, but
> IIUC, you are trying to avoid triggering a second round of reclaim in an
> already dead memcg, right?

No this is not about the second round of the reclaim but rather
iteration racing with removal. And we want to do it as lightweight as
possible. We cannot work with memcg directly because it might have
disappeared in the mean time and we do not want to hold a reference on
it because there would be no guarantee somebody will release it later
on. So mark_dead && test_and_clear_dead would not work in this context.
[...]
-- 
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/