From: Michal Hocko <mhocko@suse.com>
To: Vasily Averin <vvs@virtuozzo.com>
Cc: Shakeel Butt <shakeelb@google.com>,
Cgroups <cgroups@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH 0/9] memcg accounting from OpenVZ
Date: Thu, 11 Mar 2021 09:35:30 +0100 [thread overview]
Message-ID: <YEnWUrYOArju66ym@dhcp22.suse.cz> (raw)
In-Reply-To: <24a416f7-9def-65c9-599e-d56f7c328d33@virtuozzo.com>
On Thu 11-03-21 10:00:17, Vasily Averin wrote:
> On 3/10/21 1:41 PM, Michal Hocko wrote:
[...]
> > That is certainly an interesting information. But for a changelog it
> > would be more appropriate to provide information about how much memory
> > user can induce and whether there is any way to limit that memory by
> > other means. How practical those other means are and which usecases will
> > benefit from the containment.
>
> Right now I would like to understand how should I argument my requests about
> accounting of new kind of objects.
>
> Which description it enough to enable object accounting?
Doesn't the above paragraph give you a hint?
> Could you please specify some edge rules?
There are no strong rules AFAIK. I would say that it is important is
that the user can trigger a lot of or unbound amount of objects.
> Should I push such patches trough this list?
yes linux-mm and ccing memcg maintainers is the proper way. It would be
great to CC maintainers of the affected subsystem as well.
> Is it probably better to send them to mailing lists of according subsystems?
> Should I notify them somehow at least?
>
> "untrusted netadmin inside memcg-limited container can create unlimited number of routing entries, trigger OOM on host that will be unable to find the reason of memory shortage and kill huge"
>
> "each mount inside memcg-limited container creates non-accounted mount object,
> but new mount namespace creation consumes huge piece of non-accounted memory for cloned mounts"
>
> "unprivileged user inside memcg-limited container can create non-accounted multi-page per-thread kernel objects for LDT"
>
> "non-accounted multi-page tty objects can be created from inside memcg-limited container"
>
> "unprivileged user inside memcg-limited container can trigger creation of huge number of non-accounted fasync_struct objects"
OK, that sounds better to me. It would be also great if you can mention
whether there are any other means to limit those objects if there are
any.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-03-11 8:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 8:03 Vasily Averin
2021-03-09 21:12 ` Shakeel Butt
2021-03-10 10:17 ` Vasily Averin
2021-03-10 10:41 ` Michal Hocko
2021-03-11 7:00 ` Vasily Averin
2021-03-11 8:35 ` Michal Hocko [this message]
[not found] ` <360b4c94-8713-f621-1049-6bc0865c1867@virtuozzo.com>
2021-03-15 13:27 ` [PATCH v2 8/8] memcg: accounting for ldt_struct objects Borislav Petkov
2021-03-15 15:48 ` Shakeel Butt
2021-03-15 15:58 ` Michal Hocko
2021-03-15 15:59 ` Borislav Petkov
[not found] ` <8196f732-718e-0465-a39c-62668cc12c2b@virtuozzo.com>
2021-03-15 15:14 ` [PATCH v2 2/8] memcg: accounting for ip6_dst_cache David Ahern
[not found] ` <cb893761-cf6e-fa92-3219-712e485259b4@virtuozzo.com>
2021-03-15 15:14 ` [PATCH v2 3/8] memcg: accounting for fib_rules David Ahern
[not found] ` <d569bf43-b30a-02af-f7ad-ccc794a50589@virtuozzo.com>
2021-03-15 15:15 ` [PATCH v2 4/8] memcg: accounting for ip_fib caches David Ahern
[not found] ` <4eb97c88-b87c-6f6e-3960-b1a61b46d380@virtuozzo.com>
2021-03-15 15:56 ` [PATCH v2 5/8] memcg: accounting for fasync_cache Shakeel Butt
[not found] ` <85b5f428-294b-af57-f496-5be5fddeeeea@virtuozzo.com>
2021-03-15 15:13 ` [PATCH v2 1/8] memcg: accounting for fib6_nodes cache David Ahern
2021-03-15 15:23 ` Shakeel Butt
2021-03-15 17:09 ` Jakub Kicinski
2021-03-15 19:24 ` Shakeel Butt
2021-03-15 19:32 ` Roman Gushchin
2021-03-15 19:35 ` Jakub Kicinski
2021-03-11 15:14 ` [PATCH 0/9] memcg accounting from OpenVZ Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YEnWUrYOArju66ym@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=shakeelb@google.com \
--cc=vdavydov.dev@gmail.com \
--cc=vvs@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox