Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp1205886rdd; Wed, 10 Jan 2024 11:55:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IEC5LSkrn7vGg5K0wxoROLyAAJfXaFDuMigf4u7Pxca9gKupLcOHhYZfftC+w3ZzLkNnY3U X-Received: by 2002:a05:6808:124c:b0:3bc:3046:94b1 with SMTP id o12-20020a056808124c00b003bc304694b1mr144559oiv.99.1704916544499; Wed, 10 Jan 2024 11:55:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704916544; cv=none; d=google.com; s=arc-20160816; b=BhfvSusqFMmU8rEMPhgTRIHBh5MAZUJT7gyVuQlmWvgkPjLqh/rr6TBhKZ5+ivNTEU HPe1h+xM9NY3ZSUd5Yenb+t3+lnKTOraD/q2yHC0YXcUqEzPHNRKGqaJiKcA11IvX30l L2/oBvQcC4XCp+ucv2EgcNFfLm/wWt4bhuzM9d6DCeBRlNDdJS/UnDgphCUXliJXH+mA kAvHZ/bfMNhBbADum1R8xVAJmOq1vltKeUGcF7ZM+DUz2DuFk80C9vKo1HYlcVPplai3 f0GDXgOLnOzevdX5wzk4ZiyTEvA5vef9ge+t+ktn+VWTsRoFaPKgzPiNSAi005y7nXuD SHOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:references:from:subject:cc:to:message-id:date :content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:dkim-signature; bh=Dv0HZGBN+U9xwBGM8LkRfWs2Tr/56cVFCHtin71p6Sg=; fh=uEXa8VohJuSw9ua5uBs+/rAAAmLzNaMuYUmBYCDgDK0=; b=EQT4W51DXC0I7rbmm1W0jHub4r69YSyZFzRVg9jv286eUgrXcnPuf8VhLVOVQGP+Rs F9F7JLDXWqGoQsMDhO+jfJfkhT5FBzqUV5NPkQ0vVwciQw6w382JjAJexccp584FrK0y n6jpz0Dj40fhWLYPGDYbfi4bDqjUJNWRp+9rA8wzZidyEZjV+/2NZQJ2s4i0Ah9J43ZB Ncn7bgQd9o2TypDUwqGbtWM6uPuYrPgsM493n12Mor4/6pJgvHvdiMLvs6azTStnBfy4 vLfflLqH/xYEvU7keEcrPWznGUSXvdkmV6b91vasJoxr7Pk/5qItkCas4Fq2NO5luBUA JrhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=U3fJXjHd; spf=pass (google.com: domain of linux-kernel+bounces-22688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22688-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id q6-20020a0c9a46000000b0067f8c92249csi5064193qvd.78.2024.01.10.11.55.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 11:55:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-22688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=U3fJXjHd; spf=pass (google.com: domain of linux-kernel+bounces-22688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22688-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E73201C20A41 for ; Wed, 10 Jan 2024 19:55:43 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ADCA24EB29; Wed, 10 Jan 2024 19:55:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U3fJXjHd" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C56BB4E1BA; Wed, 10 Jan 2024 19:55:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F7E5C433C7; Wed, 10 Jan 2024 19:55:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704916530; bh=KwO40mF2TaGoN9OywGDTZ0ebE2f6XtctCT+Z4+jxzak=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=U3fJXjHdIbN5pHeqJe99LWZstSLQomhmaZKWvn8P4G9sF0cCXE+MEV/W3mUYiEzhI +R5ZoG/uPY2cUchRVtyDdPQVpwi9uNj/sWgmJ1y3bwS1ycrTfK66BjmN48RniJrpK5 XTWrQCDXo9wUjHBOFJIsLPJepaqkqlYl8Lj9xiu8yGYiO3UzOLYbLfH6PSC+6cjxR/ s9gltdJ523USV1DL0Ily/xIyv9G6aMHgIFALMQSVt899aCyVXZUuS2+/CRKTaELt+D uasHmHF9U8uY4QdKzdepD8N5yL+3GTm6htCVv/ePcjhzO416aJUjuOvLB0wVWbrzmb oHp31IMyt04jg== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 10 Jan 2024 21:55:24 +0200 Message-Id: To: "Haitao Huang" , , , , , , , , , , , , Cc: , , , , , , Subject: Re: [PATCH v6 01/12] cgroup/misc: Add per resource callbacks for CSS events From: "Jarkko Sakkinen" X-Mailer: aerc 0.15.2 References: <20231030182013.40086-1-haitao.huang@linux.intel.com> <20231030182013.40086-2-haitao.huang@linux.intel.com> In-Reply-To: On Tue Jan 9, 2024 at 5:37 AM EET, Haitao Huang wrote: > On Wed, 15 Nov 2023 14:25:59 -0600, Jarkko Sakkinen = =20 > wrote: > > > On Mon Oct 30, 2023 at 8:20 PM EET, Haitao Huang wrote: > >> From: Kristen Carlson Accardi > >> > >> The misc cgroup controller (subsystem) currently does not perform > >> resource type specific action for Cgroups Subsystem State (CSS) events= : > >> the 'css_alloc' event when a cgroup is created and the 'css_free' even= t > >> when a cgroup is destroyed. > >> > >> Define callbacks for those events and allow resource providers to > >> register the callbacks per resource type as needed. This will be > >> utilized later by the EPC misc cgroup support implemented in the SGX > >> driver. > >> > >> Also add per resource type private data for those callbacks to store a= nd > >> access resource specific data. > >> > >> Signed-off-by: Kristen Carlson Accardi > >> Co-developed-by: Haitao Huang > >> Signed-off-by: Haitao Huang > >> --- > >> V6: > >> - Create ops struct for per resource callbacks (Jarkko) > >> - Drop max_write callback (Dave, Michal) > >> - Style fixes (Kai) > >> --- > >> include/linux/misc_cgroup.h | 14 ++++++++++++++ > >> kernel/cgroup/misc.c | 27 ++++++++++++++++++++++++--- > >> 2 files changed, 38 insertions(+), 3 deletions(-) > >> > >> diff --git a/include/linux/misc_cgroup.h b/include/linux/misc_cgroup.h > >> index e799b1f8d05b..5dc509c27c3d 100644 > >> --- a/include/linux/misc_cgroup.h > >> +++ b/include/linux/misc_cgroup.h > >> @@ -27,16 +27,30 @@ struct misc_cg; > >> > >> #include > >> > >> +/** > >> + * struct misc_operations_struct: per resource callback ops. > >> + * @alloc: invoked for resource specific initialization when cgroup i= s =20 > >> allocated. > >> + * @free: invoked for resource specific cleanup when cgroup is =20 > >> deallocated. > >> + */ > >> +struct misc_operations_struct { > >> + int (*alloc)(struct misc_cg *cg); > >> + void (*free)(struct misc_cg *cg); > >> +}; > > > > Maybe just misc_operations, or even misc_ops? > > > > With Michal's suggestion to make ops per-resource-type, I'll rename this = =20 > misc_res_ops (I was following vm_operations_struct as example) > > >> + > >> /** > >> * struct misc_res: Per cgroup per misc type resource > >> * @max: Maximum limit on the resource. > >> * @usage: Current usage of the resource. > >> * @events: Number of times, the resource limit exceeded. > >> + * @priv: resource specific data. > >> + * @misc_ops: resource specific operations. > >> */ > >> struct misc_res { > >> u64 max; > >> atomic64_t usage; > >> atomic64_t events; > >> + void *priv; > > > > priv is the wrong patch, it just confuses the overall picture heere. > > please move it to 04/12. Let's deal with the callbacks here. > > > > Ok > > >> + const struct misc_operations_struct *misc_ops; > >> }; > > > > misc_ops would be at least consistent with this, as misc_res also has a= n > > acronym. > > > >> > >> /** > >> diff --git a/kernel/cgroup/misc.c b/kernel/cgroup/misc.c > >> index 79a3717a5803..d971ede44ebf 100644 > >> --- a/kernel/cgroup/misc.c > >> +++ b/kernel/cgroup/misc.c > >> @@ -383,23 +383,37 @@ static struct cftype misc_cg_files[] =3D { > >> static struct cgroup_subsys_state * > >> misc_cg_alloc(struct cgroup_subsys_state *parent_css) > >> { > >> + struct misc_cg *parent_cg, *cg; > >> enum misc_res_type i; > >> - struct misc_cg *cg; > >> + int ret; > >> > >> if (!parent_css) { > >> - cg =3D &root_cg; > >> + parent_cg =3D cg =3D &root_cg; > >> } else { > >> cg =3D kzalloc(sizeof(*cg), GFP_KERNEL); > >> if (!cg) > >> return ERR_PTR(-ENOMEM); > >> + parent_cg =3D css_misc(parent_css); > >> } > >> > >> for (i =3D 0; i < MISC_CG_RES_TYPES; i++) { > >> WRITE_ONCE(cg->res[i].max, MAX_NUM); > >> atomic64_set(&cg->res[i].usage, 0); > >> + if (parent_cg->res[i].misc_ops && parent_cg->res[i].misc_ops->alloc= ) =20 > >> { > >> + ret =3D parent_cg->res[i].misc_ops->alloc(cg); > >> + if (ret) > >> + goto alloc_err; > > > > The patch set only has a use case for both operations defined - any > > partial combinations should never be allowed. > > > > To enforce this invariant you could create a set of operations (written > > out of top of my head): > > > > static int misc_res_init(struct misc_res *res, struct misc_ops *ops) > > { > > if (!misc_ops->alloc) { > > pr_err("%s: alloc missing\n", __func__); > > return -EINVAL; > > } > > > > if (!misc_ops->free) { > > pr_err("%s: free missing\n", __func__); > > return -EINVAL; > > } > > > > res->misc_ops =3D misc_ops; > > return 0; > > } > > > > static inline int misc_res_alloc(struct misc_cg *cg, struct misc_res = =20 > > *res) > > { > > int ret; > > > > if (!res->misc_ops) > > return 0; > > =09 > > return res->misc_ops->alloc(cg); > > } > > > > static inline void misc_res_free(struct misc_cg *cg, struct misc_res = =20 > > *res) > > { > > int ret; > > > > if (!res->misc_ops) > > return 0; > > =09 > > return res->misc_ops->alloc(cg); > > } > > > > Now if anything has misc_ops, it will also always have *both* callback, > > and nothing half-baked gets in. > > > > The above loops would be then: > > > > for (i =3D 0; i < MISC_CG_RES_TYPES; i++) { > > WRITE_ONCE(cg->res[i].max, MAX_NUM); > > atomic64_set(&cg->res[i].usage, 0); > > ret =3D misc_res_alloc(&parent_cg->res[i]); > > if (ret) > > goto alloc_err; > > > > Cleaner and better guards for state consistency. In 04/12 you need to > > then call misc_res_init() instead of direct assignment. > > > > BR, Jarkko > > Will combine these with the use of a static operations array suggested by= =20 > Michal. OK, great, thanks! BR, Jarkko