linux-kernel - Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit

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: <20171120123933.fh5mnslggk4kys7d@dhcp22.suse.cz>
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