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:	Fri, 11 Mar 2016 14:49:34 +0300
From:	Vladimir Davydov <vdavydov@...tuozzo.com>
To:	Michal Hocko <mhocko@...nel.org>
CC:	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-mm@...ck.org>, <cgroups@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <kernel-team@...com>
Subject: Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below
 usage

On Fri, Mar 11, 2016 at 10:53:09AM +0100, Michal Hocko wrote:
> > OTOH memory.low and memory.high are perfect to be changed dynamically,
> > basing on containers' memory demand/pressure. A load manager might want
> > to reconfigure these knobs say every 5 seconds. Spawning a thread per
> > each container that often would look unnecessarily overcomplicated IMO.
> 
> The question however is whether we want to hide a potentially costly
> operation and have it unaccounted and hidden in the kworker context.

There's already mem_cgroup->high_work doing reclaim in an unaccounted
context quite often if tcp accounting is enabled. And there's kswapd.
memory.high knob is for the root only so it can't be abused by an
unprivileged user. Regarding a privileged user, e.g. load manager, it
can screw things up anyway, e.g. by configuring sum of memory.low to be
greater than total RAM on the host and hence driving kswapd mad.

> I mean fork() + write() doesn't sound terribly complicated to me to have
> a rather subtle behavior in the kernel.

It'd be just a dubious API IMHO. With memory.max everything's clear: it
tries to reclaim memory hard, may stall for several seconds, may invoke
OOM, but if it finishes successfully we have memory.current less than
memory.max. With this patch memory.high knob behaves rather strangely:
it might stall, but there's no guarantee you'll have memory.current less
than memory.high; moreover, according to the documentation it's OK to
have memory.current greater than memory.high, so what's the point in
calling synchronous reclaim blocking the caller?

Thanks,
Vladimir

Powered by blists - more mailing lists