From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 971CEC433F5 for ; Wed, 1 Jun 2022 13:05:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDD356B00AF; Wed, 1 Jun 2022 09:05:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8DD28D000E; Wed, 1 Jun 2022 09:05:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D7EEC6B00B3; Wed, 1 Jun 2022 09:05:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C45E86B00AF for ; Wed, 1 Jun 2022 09:05:39 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 846B720A7B for ; Wed, 1 Jun 2022 13:05:39 +0000 (UTC) X-FDA: 79529688798.02.5987DCA Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf15.hostedemail.com (Postfix) with ESMTP id 77CBBA0051 for ; Wed, 1 Jun 2022 13:05:14 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id EE4181F91B; Wed, 1 Jun 2022 13:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654088735; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4HT0cgYwgnfjABAMP2rxuw2kn3xpQBu05UKapDm2w2s=; b=mgcnDmbod7AS0jNFNTgBmt5TtSf2GwrgGuolVn+us6tDy1LsfQXEkJxCtalFkWgsGGxU9k RIKMb19XyB7rYQvf9JjWQ6fLrKnMQqmLnmzI02U82zAdXYGoSM0kn+mxic/yRR2Gw6Uqbh 7du7yE4XF3wYNtXL8JVGOL42tHBF9t0= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 434BF2C141; Wed, 1 Jun 2022 13:05:35 +0000 (UTC) Date: Wed, 1 Jun 2022 15:05:34 +0200 From: Michal Hocko To: Michal =?iso-8859-1?Q?Koutn=FD?= , Roman Gushchin Cc: Vasily Averin , Andrew Morton , kernel@openvz.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Vlastimil Babka , Muchun Song , cgroups@vger.kernel.org Subject: Re: [PATCH mm v3 0/9] memcg: accounting for objects allocated by mkdir cgroup Message-ID: References: <06505918-3b8a-0ad5-5951-89ecb510138e@openvz.org> <3e1d6eab-57c7-ba3d-67e1-c45aa0dfa2ab@openvz.org> <3a1d8554-755f-7976-1e00-a0e7fb62c86e@openvz.org> <118bcb39-1281-0d1d-b163-3f6bcc99c3e2@openvz.org> <20220601091543.GA21320@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 77CBBA0051 X-Stat-Signature: jo9ru6t8mdjc1hi5hx9rqe8sf8mabnh7 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=mgcnDmbo; spf=pass (imf15.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1654088714-367111 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 01-06-22 11:32:26, Michal Hocko wrote: > On Wed 01-06-22 11:15:43, Michal Koutny wrote: > > On Wed, Jun 01, 2022 at 06:43:27AM +0300, Vasily Averin wrote: > > > CT-901 /# cat /sys/fs/cgroup/memory/cgroup.subgroups_limit > > > 512 > > > CT-901 /# echo 3333 > /sys/fs/cgroup/memory/cgroup.subgroups_limit > > > -bash: echo: write error: Operation not permitted > > > CT-901 /# echo 333 > /sys/fs/cgroup/memory/cgroup.subgroups_limit > > > -bash: echo: write error: Operation not permitted > > > > > > I doubt this way can be accepted in upstream, however for OpenVz > > > something like this it is mandatory because it much better > > > than nothing. > > > > Is this customization of yours something like cgroup.max.descendants on > > the unified (v2) hierarchy? (Just curious.) > > > > (It can be made inaccessible from within the subtree either with cgroup > > ns or good old FS permissions.) > > So we already do have a limit to prevent somebody from running away with > the number of cgroups. Nice! I was not aware of that and I guess this > looks like the right thing to do. So do we need more control and > accounting that this? I have checked the actual implementation and noticed that cgroups are uncharged when offlined (rmdir-ed) which means that an adversary could still trick the limit and runaway while still consuming resources. Roman, I guess the reason for this implementation was to avoid limit to trigger on setups with memcgs which can take quite some time to die? Would it make sense to make the implementation more strict to really act as gate against potential cgroups count runways? -- Michal Hocko SUSE Labs