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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA153C433E0 for ; Thu, 11 Mar 2021 08:35:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2564D64F87 for ; Thu, 11 Mar 2021 08:35:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2564D64F87 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8FC788D028A; Thu, 11 Mar 2021 03:35:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8ADA18D0250; Thu, 11 Mar 2021 03:35:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74FC48D028A; Thu, 11 Mar 2021 03:35:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id 555088D0250 for ; Thu, 11 Mar 2021 03:35:33 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 13D07180ACEEC for ; Thu, 11 Mar 2021 08:35:33 +0000 (UTC) X-FDA: 77906934546.21.8F72244 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf28.hostedemail.com (Postfix) with ESMTP id AF9B8200038F for ; Thu, 11 Mar 2021 08:35:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1615451731; 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=SPSvV0WAkJhngu3aMbeieIGtboHQE6ozlBVf1GQ8Sww=; b=hMByrvkbSYioy7yXZtEnsXK7gQssCDpTUh7KNFoXt5p4SQbgBT8MSPdoyKSf/inCqJUI3u SPR5qwEBCYsPA7VxCzZiscKONdpqLeHcJwUVfRfC0MDaZIzS5FX392ldn/NZBvp0ZuhVZB pKmxwq+CmSCGhgO0QwbafOqq4vIxjAc= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6948CAC17; Thu, 11 Mar 2021 08:35:31 +0000 (UTC) Date: Thu, 11 Mar 2021 09:35:30 +0100 From: Michal Hocko To: Vasily Averin Cc: Shakeel Butt , Cgroups , Linux MM , Johannes Weiner , Vladimir Davydov Subject: Re: [PATCH 0/9] memcg accounting from OpenVZ Message-ID: References: <5affff71-e503-9fb9-50cb-f6d48286dd52@virtuozzo.com> <24a416f7-9def-65c9-599e-d56f7c328d33@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24a416f7-9def-65c9-599e-d56f7c328d33@virtuozzo.com> X-Stat-Signature: tf9o8iwj6nh5badzwwz9pszdmdux371k X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AF9B8200038F Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615451733-23454 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 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