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:	Wed, 3 Jun 2009 12:52:28 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Daisuke Nishimura <nishimura@....nes.nec.co.jp>
Cc:	LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Li Zefan <lizf@...fujitsu.com>, Paul Menage <menage@...gle.com>
Subject: Re: [PATCH mmotm 2/2] memcg: allow mem.limit bigger than
 memsw.limit iff unlimited

On Wed, 3 Jun 2009 11:50:27 +0900
Daisuke Nishimura <nishimura@....nes.nec.co.jp> wrote:

> Now users cannot set mem.limit bigger than memsw.limit.
> This patch allows mem.limit bigger than memsw.limit iff mem.limit==unlimited.
> 
> By this, users can set memsw.limit without setting mem.limit.
> I think it's usefull if users want to limit memsw only.
> They must set mem.limit first and memsw.limit to the same value now for this purpose.
> They can save the first step by this patch.
> 

I don't like this. No benefits to users.
The user should know when they set memsw.limit they have to set memory.limit.
This just complicates things.

If you want to do this, add an interface as
  memory.all.limit_in_bytes (or some better name)
and allow to set memory.limit and memory.memsw.limit _at once_.

But I'm not sure it's worth to try. Saving user's few steps by the kenerl patch ?

Thanks,
-Kame


> Signed-off-by: Daisuke Nishimura <nishimura@....nes.nec.co.jp>
> ---
>  mm/memcontrol.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 6629ed2..2b63cb1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1742,11 +1742,12 @@ static int mem_cgroup_resize_limit(struct mem_cgroup *memcg,
>  		/*
>  		 * Rather than hide all in some function, I do this in
>  		 * open coded manner. You see what this really does.
> -		 * We have to guarantee mem->res.limit < mem->memsw.limit.
> +		 * We have to guarantee mem->res.limit < mem->memsw.limit,
> +		 * except for mem->res.limit == RESOURCE_MAX(unlimited) case.
>  		 */
>  		mutex_lock(&set_limit_mutex);
>  		memswlimit = res_counter_read_u64(&memcg->memsw, RES_LIMIT);
> -		if (memswlimit < val) {
> +		if (val != RESOURCE_MAX && memswlimit < val) {
>  			ret = -EINVAL;
>  			mutex_unlock(&set_limit_mutex);
>  			break;
> @@ -1789,11 +1790,12 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg,
>  		/*
>  		 * Rather than hide all in some function, I do this in
>  		 * open coded manner. You see what this really does.
> -		 * We have to guarantee mem->res.limit < mem->memsw.limit.
> +		 * We have to guarantee mem->res.limit < mem->memsw.limit,
> +		 * except for mem->res.limit == RESOURCE_MAX(unlimited) case.
>  		 */
>  		mutex_lock(&set_limit_mutex);
>  		memlimit = res_counter_read_u64(&memcg->res, RES_LIMIT);
> -		if (memlimit > val) {
> +		if (memlimit != RESOURCE_MAX && memlimit > val) {
>  			ret = -EINVAL;
>  			mutex_unlock(&set_limit_mutex);
>  			break;
> 

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ