[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130729161026.GD22605@mtj.dyndns.org>
Date: Mon, 29 Jul 2013 12:10:26 -0400
From: Tejun Heo <tj@...nel.org>
To: Michal Hocko <mhocko@...e.cz>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
cgroups@...r.kernel.org, containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, kent.overstreet@...il.com,
Li Zefan <lizefan@...wei.com>,
Glauber Costa <glommer@...il.com>,
Johannes Weiner <hannes@...xchg.org>
Subject: Re: memcg creates an unkillable task in 3.2-rc2
Hello,
On Mon, Jul 29, 2013 at 11:51:09AM +0200, Michal Hocko wrote:
> Isn't this a bug in freezer then? I am not familiar with the freezer
> much but memcg oom handling seems correct to me. The task is sleeping
> KILLABLE and fatal_signal_pending in mem_cgroup_handle_oom will tell us
> to bypass the charge and let the taks go away.
Is the problem a frozen task not being killed even when SIGKILL is
received? If so, it is a known problem and a side-effect of
cgroup_freezer (ab)using and making the existing power management
freezer visible to userland without really thinking about the
implications. :(
So, yeah, if you use cgroup_freezer now, the tasks will get stuck in
states which aren't well defined when visible from userland and will
just stay there until unfrozen no matter what. Yet another reason
I'll be screaming like a banshee at anyone who says that cgroup is
built to delegate subtree access rights to !root users.
It's on the to-do list but a very long term one. Right now, if you
combine userland OOM handling with freezer and whatnot, it'd be pretty
easy to get into trouble.
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists