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 5779BC369C2 for ; Tue, 22 Apr 2025 15:40:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 367866B0005; Tue, 22 Apr 2025 11:40:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33E076B0006; Tue, 22 Apr 2025 11:40:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22CB96B0008; Tue, 22 Apr 2025 11:40:23 -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 044296B0005 for ; Tue, 22 Apr 2025 11:40:22 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 22C7DC03E1 for ; Tue, 22 Apr 2025 15:40:24 +0000 (UTC) X-FDA: 83362091568.08.FB9E8C7 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) by imf01.hostedemail.com (Postfix) with ESMTP id 4746940003 for ; Tue, 22 Apr 2025 15:40:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=G0+EygSy; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745336422; a=rsa-sha256; cv=none; b=vmGI5T8MEFynDT4z2ZH+4uQjHlGDMot2BqsyPPRyorKG+diaq0Q50fxe87REKNfOs/Reiq dDKQzOex9pr7SlONBbaXeeUd8Ep8zp0O3csUwvXzK4evtOsrsqkfIu5W4TTgZa3GQMtBGv owYtUnHzN9bBaDX3tVd1J4uvNyIUfHQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=G0+EygSy; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.170 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745336422; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bsy5PJS41mGhoO54IOukmg7Bo8GKSd/BSVXvRDM5VnM=; b=rI07YDLoY6PEemIJ3IEQFHzAfQvihihBNXb7nhmxKfc+ze2K4qT6JsCrpzhn92/42PLhn8 +ZFAJcSrerO2eGJzQFETkaevBdRGBFcBs7X8ZO9PlSKdwjTL1aQP4+biQ+JZ+A7fO8QPoo TlVJxIzuSeXg+BSNiNh5lPEI9Clpm1I= Date: Tue, 22 Apr 2025 08:40:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1745336419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bsy5PJS41mGhoO54IOukmg7Bo8GKSd/BSVXvRDM5VnM=; b=G0+EygSywRwQUvJGbgX4OaUmUPOV5m9AyREzpvvQmABa7jQmA7ybaYemI9lWJYsdSiq6vm M6RsrgW+BeXi/rkjR9sarP/fQdFHgcj+rwDbKA2shRRPqB+y9QNibNa2RdQ3nGpiA0NjFw MCLOonU8x4YaRJAck7T5pP/xExUiK7M= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Christian Brauner Cc: Michal =?utf-8?Q?Koutn=C3=BD?= , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Yosry Ahmed , Tejun Heo , Greg Thelen , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [PATCH v2] memcg: introduce non-blocking limit setting option Message-ID: References: <20250419183545.1982187-1-shakeel.butt@linux.dev> <20250422-daumen-ozonbelastung-93d90ca81dfa@brauner> <20250422-synergie-bauabschnitt-5f724f1d9866@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250422-synergie-bauabschnitt-5f724f1d9866@brauner> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4746940003 X-Stat-Signature: icn3g4axcq1d5gn3oom3x6yi599qjhba X-HE-Tag: 1745336422-565058 X-HE-Meta: U2FsdGVkX198QwwXfowhFoRdSV2843na01Dr1FKgU+aOwU0wOLwG/W68lKVnguu4K678oT3BFFUYJd2/55t9qpGdfHSujI30lB+gHmVRtdixk6F2b3tQkj86ys1oXEapWq+bmpcxHKrgi0GKc4RnoFOuxsC7uynouKKcQ20bJudkF/6OzPBPTDprhQ5BL1QLQu4HjvuoRzNUtRj2tMdtGEZI1taceJXmVS8AGfSNml6tmgsbZVpxxpl1L7u/eywkQRr3IijjdLtMpXXJ+iR3CfyOXbZKNCgD7XrGdIVj7Zoe5HlOejxorE1+5Lj3mBgHSEf7tBOE/zstq7m+V2E1FPFUhbZapjXyG7YX+ajbk9Zv6XqWxHRHbOOEVwYaOf/u5Wxw816XrbjDGJXMIjX6MssBP/gwiUwwc0FhEq2VaJ458VeeRM9F64+KFyftFPdFDSFFjIBn+FogMdJ9n8FkNB6q1KdgmWsbCBQeRX8oRbct0Baxd1ZL1V8x/wSJh06UA03Nasv/eOKWpy+uXSgM15LLU6FVRtUbBXUv5syKmPE+7NSm0Bciyt3T9NLkYoWqGLpJzvYz6j1gyWWvum7PHLjNZ+obEeQMqcFNqiLz5f6OxukbLP6/geIhIA2GMF45mwkAiRIU+6jZ/CcvGwMUYSN5XZG8yU6LwYBRN7IIXsKUUV1grZzoTRMPfkycBZBJLxRFiPuzZaLPATvyPDO72OczYiayhNOVmwlNB3ZzgMJw40jFMCOwujcXO9C7la0LtQvsqSsYmPkq/KSfiSln/7gp1iU7swT0PpZKG0zRoWcw3ZsMI0+AMcbLzIflEdjhHXs78cyrE5oRcm13dYueO69mMbWwM/TOuWVl2DHl9IUEbzITEiL/le0B98wpIClckLbv9haW0MuRfqRB/uuzoXV3yIeSLlI2N/f/bCA8Y/20tG9yTbH8y6Po3hs4J1u7MItJOCnJTK3jkNJN0q/ FEX1lkSG YL8E4UqT7/pymJ/F42L1mgMge8idolNMR3Ki1kq6i82TVCma0fmq5p+2YVhxXw09kt1+hJlqlxDZoMZHEug0zFjpu2Hb2yAWNcSsqSpQEw1XoBgTNmsa6iDWSB11TSti/C+H5BcJzDjv3sNSz0O0OBjyQ6xGLaaMIfJhO39TSt1ZjoKvwiswEhinTku0YbS8u4ASdYRKVCAH+hrXHNggLHcE59D6yPmv3RMJOFruAMaNcLvY= 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: List-Subscribe: List-Unsubscribe: On Tue, Apr 22, 2025 at 11:48:23AM +0200, Christian Brauner wrote: > On Tue, Apr 22, 2025 at 11:31:23AM +0200, Michal Koutný wrote: > > On Tue, Apr 22, 2025 at 11:23:17AM +0200, Christian Brauner wrote: > > > As written this isn't restricted to admin processes though, no? So any > > > unprivileged container can open that file O_NONBLOCK and avoid > > > synchronous reclaim? > > > > > > Which might be fine I have no idea but it's something to explicitly > > > point out > > > > It occurred to me as well but I think this is fine -- changing the > > limits of a container is (should be) a privileged operation already > > (ensured by file permissions at opening). > > IOW, this doesn't allow bypassing the limits to anyone who couldn't have > > been able to change them already. > > Hm, can you explain what you mean by a privileged operation here? If I > have nested containers with user namespaces with delegated cgroup tress, > i.e., chowned to them and then some PID 1 or privileged container > _within the user namespace_ lowers the limit and uses O_NONBLOCK then it > won't trigger synchronous reclaim. Again, this might all be fine I'm > just trying to understand. I think Michal's point is (which I agree with) that if a process has the privilege to change the limit of a cgroup then it is ok for that process to use O_NONBLOCK to avoid sync reclaim. This new functionality is not enabling anyone to bypass their limits. In your example of PID 1 or privileged container, yes with O_NONBLOCK the limit updater will not trigger sync reclaim but whoever is running in that cgroup will eventually hit the sync reclaim in their next charge request.