linux-kernel - Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

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: <20151215202235.GB15672@cmpxchg.org>
Date:	Tue, 15 Dec 2015 15:22:35 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	Vladimir Davydov <vdavydov@...tuozzo.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2

On Tue, Dec 15, 2015 at 06:21:28PM +0100, Michal Hocko wrote:
> > AFAICS such anon memory protection has a side-effect: real-life
> > workloads need page cache to run smoothly (at least for mapping
> > executables). Disabling swapping would switch pressure to page caches,
> > resulting in performance degradation. So, I don't think per memcg swap
> > limit can be abused to boost your workload on an overcommitted system.
> 
> Well, you can trash on the page cache which could slow down the workload
> but the executable pages get an additional protection so this might be
> not sufficient and still trigger a massive disruption on the global level.

No, this is a real consequence. If you fill your available memory with
mostly unreclaimable memory and your executables start thrashing you
might not make forward progress for hours. We don't have a swap token
for page cache.

> Just to make it clear. I am not against the new way of the swap
> accounting. It is much more clear then the previous one. I am just
> worried it allows for an easy misconfiguration and we do not have any
> measures to help the global system healthiness. I am OK with the patch
> if we document the risk for now. I still think we will end up doing some
> heuristic to throttle for a large unreclaimable high limit excess in the
> future but I agree this shouldn't be the prerequisite.

It's unclear to me how the previous memory+swap counters did anything
tangible for global system health with malicious/buggy workloads. If
anything, the previous model seems to encourage blatant overcommit of
workloads on the flawed assumption that global pressure could always
claw back memory, including anonymous pages of untrusted workloads,
which does not actually work in practice. So I'm not sure what new
risk you are referring to here.

As far as the high limit goes, its job is to contain cache growth and
throttle applications during somewhat higher-than-expected consumption
peaks; not to contain "large unreclaimable high limit excess" from
buggy or malicious applications, that's what the hard limit is for.

All in all, it seems to me we should leave this discussion to actual
problems arising in the real world. There is a lot of unfocussed
speculation in this thread about things that might go wrong, without
much thought put into whether these scenarios are even meaningful or
real or whether they are new problems that come with the swap limit.
--
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/