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 CB9E9C6FD1F for ; Wed, 22 Mar 2023 15:57:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 318EB6B0071; Wed, 22 Mar 2023 11:57:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A14A6B0072; Wed, 22 Mar 2023 11:57:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 143316B0075; Wed, 22 Mar 2023 11:57:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F23436B0071 for ; Wed, 22 Mar 2023 11:57:31 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C339BC052D for ; Wed, 22 Mar 2023 15:57:31 +0000 (UTC) X-FDA: 80596989102.20.411F42F Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf05.hostedemail.com (Postfix) with ESMTP id C908C100005 for ; Wed, 22 Mar 2023 15:57:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=nTk5m38N; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679500649; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=izrxL5uNy/RlGAZkpdzzMJcPSf/6R/YxjFD0TFNLUvA=; b=8AjOZy02vxiAG4P7LKag5cKkibOtgTKDn7gpAOwjbTQJhvySrPm5IOAhocvq2dcixUiRVG LZhrnud4eaFCof3nbh3kqtYA17Qxi3rTK9B16dCKDr2k4vPHR0h2DwJKoyTIaJSEmpymn7 MyU0oXHsu5UuLUFrI+i5wXnDCJZrPYk= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=nTk5m38N; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679500649; a=rsa-sha256; cv=none; b=tzwEwd2MFSBEtYSxQzvP2+6NjOw4CZstGw9gElkHQcjY4SJk/KXAegEoXCXV3MBLRfvd+U +ZGzIZcK+JgqWTVOh25fu86PtYIAnImHV504gptTJffMTYwlc9Hu7sJ8Dx7MfgfIaBhOIf 4CZR7PEh7nlJLRqkJlcDGZgcr5RMA04= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1811A20F93; Wed, 22 Mar 2023 15:57:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1679500647; 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=izrxL5uNy/RlGAZkpdzzMJcPSf/6R/YxjFD0TFNLUvA=; b=nTk5m38N9QXJDWuO5Sl5xVqlCA5xhBf5fUEB/K4SYKENk8A9HFIPvTxi0olsuhYXtji1/T NS20L8cWUc/NC/9haLylj9pyg+PWaPMt2xi6uA6/qMUASS9f5AwMfT3U+RiZe7RXClP0hk 7LH3Ziwa3w7bLzPJYtr9kH5uwZmnPnw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E9FD513416; Wed, 22 Mar 2023 15:57:26 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id BnvONmYlG2TWXgAAMHmgww (envelope-from ); Wed, 22 Mar 2023 15:57:26 +0000 Date: Wed, 22 Mar 2023 16:57:26 +0100 From: Michal Hocko To: Florian Schmidt Cc: Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] memcg v1: provide read access to memory.pressure_level Message-ID: References: <20230322142525.162469-1-flosch@nutanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230322142525.162469-1-flosch@nutanix.com> X-Rspamd-Queue-Id: C908C100005 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: pfext371yy78g39xue5myn5m39iu4iiz X-HE-Tag: 1679500648-48041 X-HE-Meta: U2FsdGVkX1/fvL9vT7kCtVF/BIbWJ/T7+H8XUjxLVqkatRRD3QtKyTtyoBT+USRkV8f2xnleXtfQq4PcDms91mkHbfwnNPJZYt0RZSPInOraBrbXvbMmToKHob5vT/+0V/uHqbi6nwYoBtenSQtjnV62Qe9bYApMjKFFKO4gVl3KIrFMoUFziP0R3vkKkjGzIGwlJKw40I+dh06VWiqa1YmcADmETg/MrSf0Apelv699wmGNsNBHEfMZI8PDFYNsrN2dJEcHIFMpGZ3GbEURw6xbtTryrmkQWOj4qwp+zkqrjef/VUPGzfZvmj+kp81H66PebNRCY8hurMhzaDcxGyi1wxCRSOBYLNkfF34MoKqRQKw/cAMAe7V6OqWTYKzv0f47K8QRz9/9nAHAwpVQ+X3YEdvjNUKtvAuUeOJKtFHehDebHcHEeKt9ZCjHRbFqfQnGviNfWB387oPUyC2ocV6VCHhBQH3A3DkC0qu/6me2M6OtFJCyTGXvmE+KhKazHd5AyY9XeD2BR842Usuv9b1LWX1XDMHM4lD3q9HlwXQhF/RHOCcKxerRwb02His+qXEjbx4rZU/MEDrFXEkb7V/Y+b9M9cT22pVOheCtAIG6UQYVaXQPt+VoQinZNBseApcAM3mZcul3nSRKjmTESFcandu0/yL1dg3CYmDX0Ib4S9Rer7tx0HlfTlQseopQ2AWrgWQOhX3PBzBborvJg9NWCtRtf5xCG6S1hnrJacOBLnrFjemAYIcEbpxYABFRTVnuODkuM16RgfTkcid27NL3hnfgSrIBBzMmIkQY0NJX9TTrGyrcLbZ4h00j4UqIy8Jh8tiLxCKhEpbbVpr5riZULSIqd3Ewk9qJOy8ha4g1IP4JEr+xJhyx7QOaFUp9DS0uYRSeVS8Tybct0SWCvIt00913La9dzM6jF89xzxorryynK1SMQtCuFLQTfqBaWMlUThwyLS7W4HqDR4G WXjWBmJ5 ixQbo+Q7AJRlgE5DwmETXYOUGZE1kQIeCfm5FNfWMdYh8bT7AFEmMckiCeJAlnfNmk/RiifBzVlIwJi1Gt1qA9+Y1TC5e4vRUWHBWxMegOLV1jKSDN2J4RJiBRnyQvYrAhwKSLgcxPIQb0yPb72dyprY8AARhC1GtNuYVhbdVROEXdFVEGNQX3PCK7S0wsdXK/kuqTLsRpMc15vgxhsXPhMAYslAIJVtYKo5pXRnLosy98RELnl4PJAiu2otpI9LDBloGje+24VOvPak= 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 22-03-23 14:25:25, Florian Schmidt wrote: > cgroups v1 has a unique way of setting up memory pressure notifications: > the user opens "memory.pressure_level" of the cgroup they want to > monitor for pressure, then open "cgroup.event_control" and write the fd > (among other things) to that file. memory.pressure_level has no other > use, specifically it does not support any read or write operations. > Consequently, no handlers are provided, and the file ends up with > permissions 000. However, to actually use the mechanism, the subscribing > user must have read access to the file and open the fd for reading, see > memcg_write_event_control(). > > This is all fine as long as the subscribing process runs as root and is > otherwise unconfined by further restrictions. However, if you add strict > access controls such as selinux, the permission bits will be enforced, > and opening memory.pressure_level for reading will fail, preventing the > process from subscribing, even as root. > > > There are several ways around this issue, but adding a dummy read > handler seems like the least invasive to me. I was struggling to see how that addresses the problem because all you need is a read permission. But then I've looked into cgroup code and learned that permissions are constructed based on available callbacks (cgroup_file_mode). This would have made the review easier ;) I have no issue with the patch. It would be great to hear from cgroup maintainers whether a concept of default permissions is something that would be useful also for other files. > I'd be interested to hear: > (a) do you think there is a less invasive way? Alternatively, we could > add a flag in cftype in include/linux/cgroup-defs.h, but that seems > more invasive for what is a legacy interface. > (b) would you be interested to take this patch, or is it too niche a fix > for a legacy subsystem? After you add your s-o-b, feel free to add Acked-by: Michal Hocko If cgroup people find a concept of default permissions for a cgroup file sound then this could be replaced by that approach but this is really an easy workaround. > --- > mm/memcontrol.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 5abffe6f8389..e48c749d9724 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -3734,6 +3734,16 @@ static u64 mem_cgroup_read_u64(struct cgroup_subsys_state *css, > } > } > > +/* > + * This function doesn't do anything useful. Its only job is to provide a read > + * handler so that the file gets read permissions when it's created. I would just reference cgroup_file_mode() in the comment to make our lifes easier and comment more helpful. > + */ > +static int mem_cgroup_dummy_seq_show(__always_unused struct seq_file *m, > + __always_unused void *v) > +{ > + return -EINVAL; > +} > + > #ifdef CONFIG_MEMCG_KMEM > static int memcg_online_kmem(struct mem_cgroup *memcg) > { > @@ -5064,6 +5074,7 @@ static struct cftype mem_cgroup_legacy_files[] = { > }, > { > .name = "pressure_level", > + .seq_show = mem_cgroup_dummy_seq_show, > }, > #ifdef CONFIG_NUMA > { > -- > 2.32.0 -- Michal Hocko SUSE Labs