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:   Mon, 20 Nov 2017 13:39:33 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Yafang Shao <laoar.shao@...il.com>
Cc:     Shakeel Butt <shakeelb@...gle.com>, Roman Gushchin <guro@...com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Tejun Heo <tj@...nel.org>, khlebnikov@...dex-team.ru,
        mka@...omium.org, Hugh Dickins <hughd@...gle.com>,
        Cgroups <cgroups@...r.kernel.org>, Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

On Mon 20-11-17 20:16:15, Yafang Shao wrote:
> 2017-11-20 20:04 GMT+08:00 Michal Hocko <mhocko@...nel.org>:
> > On Fri 17-11-17 09:49:54, Shakeel Butt wrote:
> >> On Fri, Nov 17, 2017 at 9:41 AM, Yafang Shao <laoar.shao@...il.com> wrote:
> > [...]
> >> > Of couse that is the best way.
> >> > But we can not ensue all applications will do it.
> >> > That's why I introduce a proper defalut value for them.
> >> >
> >>
> >> I think we disagree on the how to get proper default value. Unless you
> >> can restrict that all the memory allocated for a tmpfs mount will be
> >> charged to a specific memcg, you should not just pick limit of the
> >> memcg of the process mounting the tmpfs to set the default of tmpfs
> >> mount. If you can restrict tmpfs charging to a specific memcg then the
> >> limit of that memcg should be used to set the default of the tmpfs
> >> mount. However this feature is not present in the upstream kernel at
> >> the moment (We have this feature in our local kernel and I am planning
> >> to upstream that).
> >
> > I think the whole problem is that containers pretend to be independent
> > while they share a non-reclaimable resource. Fix this and you will not
> > have a problem. I am afraid that the only real fix is to make tmpfs
> > private per container instance and that is something you can easily
> > achieve in the userspace.
> >
> 
> Agree with you.

I suspect you misunderstood...

> Introduce tmpfs stat in memory cgroup, something like
> memory.tmpfs.limit
> memory.tmpfs.usage
> 
> IMHO this is the best solution.

No, you misunderstood. I do not think that we want to split tmpfs out of
the regular limit. We used to have something like that for user vs.
kernel memory accounting  in v1 and that turned to be not working well.

What you really want to do is to make a private mount per container to
ensure that the resource is really _yours_
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ