linux-kernel - Re: [PATCH 4/4] memcg: force use_hierarchy if sane

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: <20130415023552.GA9955@dhcp22.suse.cz>
Date:	Sun, 14 Apr 2013 19:35:52 -0700
From:	Michal Hocko <mhocko@...e.cz>
To:	Serge Hallyn <serge.hallyn@...ntu.com>
Cc:	Tejun Heo <tj@...nel.org>, lizefan@...wei.com,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, vgoyal@...hat.com,
	cgroups@...r.kernel.org
Subject: Re: [PATCH 4/4] memcg: force use_hierarchy if sane_behavior

On Sun 14-04-13 20:13:36, Serge Hallyn wrote:
> Quoting Tejun Heo (tj@...nel.org):
> > Turn on use_hierarchy by default if sane_behavior is specified and
> > don't create .use_hierarchy file.
> > 
> > It is debatable whether to remove .use_hierarchy file or make it ro as
> > the former could make transition easier in certain cases; however, the
> > behavior changes which will be gated by sane_behavior are intensive
> > including changing basic meaning of certain control knobs in a few
> > controllers and I don't really think keeping this piece would make
> > things easier in any noticeable way, so let's remove it.
> 
> Hi Tejun,
> 
> this actually reminds me of something that's been on my todo list to
> report for some time, but I haven't had time to find the source of the
> bug...  And maybe it's already been reported...  but
> 
> If I do
> 
> 	cd /sys/fs/cgroup/memory
> 	mkdir b
> 	cd b
> 	echo 1 > memory.use_hierarchy
> 	echo 5000 > memory.limit_in_bytes
> 	cat memory.limit_in_bytes
> 8192
> 	mkdir c
> 	cd c
> 	cat memory.use_hierarchy
> 1
> 	cat memory.limit_in_bytes
> 9223372036854775807
> 	echo $$ > tasks
> 	bash
> <killed>
> 
> So it seems the hierarchy is being enforced, but not reported in
> child limit_in_bytes files.

This is an intended behavior. Limits are not propagated to the children
because they are enforced anyway (by reclaim). The behavior would
be quite inconsistent when the parent limit would be changed later
otherwise. We only inherit properties which are enforced hierarchically:
use_hierarchy, oom_disable and swappiness.

> (Last tested tonight on 3.8.0-17-generic #27-Ubuntu fwiw)
> 
> -serge

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