Received: by 2002:a05:7412:b101:b0:e2:908c:2ebd with SMTP id az1csp2851881rdb; Wed, 15 Nov 2023 12:26:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IEV4ZhqyYElPtCR8Yn8z3HimYT7mq+WggGcmbletypSpCdHVeTykqvTpXJtGNbx7vtq13En X-Received: by 2002:a17:902:da83:b0:1cc:6597:f41a with SMTP id j3-20020a170902da8300b001cc6597f41amr6524039plx.59.1700079984245; Wed, 15 Nov 2023 12:26:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700079984; cv=none; d=google.com; s=arc-20160816; b=chmyxcjsVlBXv847guYWpqS6ukfNq0Sw54OM3L/D/GRM2V71oisW8NjLeEAD7h8KZe O0DRW4BNzNkY7d+Bft/jGGU6pvwKe9bOUpMoF0H6Efr1ldoTQWUy5uHAlsKYlgwPV3k3 4+qW3KwKH4Zer81qZWIG6Myah4iQmBcJxeqVUpF0IjThvHLUfaQD/qMTC0Y195lVIQrg wYbnZoLF1D9E/5pqM1gPsLf2LXR5cjOQsUAgHK3nrgM5Z3kbq+xf8oPwGf2Q0Qa6iUIo A9+m0rWStMZZAb0IxYWVN+1S/3MwFM+zapG7zXMt0f6h1HbGQuhOu8+Gc9aYSbnwEQ72 Yyzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:references:cc:to:from:subject :message-id:date:content-transfer-encoding:mime-version :dkim-signature; bh=t5HSSX1OsAZSVWkgcaPQGd4CYgjQtvVt4coDqeJove0=; fh=uEXa8VohJuSw9ua5uBs+/rAAAmLzNaMuYUmBYCDgDK0=; b=0MelFkuA/RxMgAstcfLTJDET8EDVh+X8zbx5lHIkneRUXpu2yU3/rj8pNDLbZ+dbpO vDqYzOpcUe4HTJ8uSBzEb+CooEDm+hK+e4uiAHqP0UKxGCRSvNBs+0nAF0ItICcil0BY P+mDck+Xm3phsX6c4kCGn3CkCWrLBUoHqJt9/nXKPiGkSEIWDNudDkt2ny3EEtKaNcP1 o93DbNivFKZz/G8oAOxsBro3wVqICvlGCQ7MYj7NONG+IfhAVZEom+Gkj59xoFhKmwXt Yl9ZzhIs0USadUfW7rihrturQvfCvTHEbuvAH7Whu31eIbCyudvXz9VdIE7jBd0SmgeT Ercw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SEcG3JwW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id iz20-20020a170902ef9400b001ce0931ba15si10154715plb.184.2023.11.15.12.26.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Nov 2023 12:26:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SEcG3JwW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 968228069343; Wed, 15 Nov 2023 12:26:21 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235685AbjKOU0M (ORCPT + 99 others); Wed, 15 Nov 2023 15:26:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235683AbjKOU0J (ORCPT ); Wed, 15 Nov 2023 15:26:09 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8A501A3; Wed, 15 Nov 2023 12:26:05 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A47D5C433C7; Wed, 15 Nov 2023 20:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700079965; bh=SOtNdL3JNKTm9VZJNKO/kZNG8OS7jX2bdSzi5ufh4lE=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=SEcG3JwWR9EHg0HanBYt9kAKoVhebzyuN8a5B/Bnjnx2gmbTSqlc5Sr68shkiBImV sHG41zk7Gtm7zoich93lUtwe4S6ME5fuKaEjIWg2/qCAjo2iq2xKZQA47SlfgO1Syi crxwNUMZRnkMvkofc/G22ogt0s2I3wDWaECpJXr9d8iguwvtXthk35q/KuJT5I+3Hg AcwMLM4Jdljot9Ty9Yqdo3dq3TLQUSJrrGaNwcmyFObPNdzaalds/F1UriqeBBIGyi uESZrM65RXUZ1BzIZIRq2UpYhBd8/4V7S/ZYoNCb8zBOGn9ZfmQGfXI7gFjqUwVmsE rNzWEH0zXxUJQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 15 Nov 2023 22:25:59 +0200 Message-Id: Subject: Re: [PATCH v6 01/12] cgroup/misc: Add per resource callbacks for CSS events From: "Jarkko Sakkinen" To: "Haitao Huang" , , , , , , , , , , , , Cc: , , , , , , 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: <20231030182013.40086-2-haitao.huang@linux.intel.com> X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 15 Nov 2023 12:26:21 -0800 (PST) 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' event > 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 and > 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; > =20 > #include > =20 > +/** > + * struct misc_operations_struct: per resource callback ops. > + * @alloc: invoked for resource specific initialization when cgroup is a= llocated. > + * @free: invoked for resource specific cleanup when cgroup is deallocat= ed. > + */ > +struct misc_operations_struct { > + int (*alloc)(struct misc_cg *cg); > + void (*free)(struct misc_cg *cg); > +}; Maybe just misc_operations, or even misc_ops? > + > /** > * 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. > + const struct misc_operations_struct *misc_ops; > }; misc_ops would be at least consistent with this, as misc_res also has an acronym. > =20 > /** > 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; > =20 > 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); > } > =20 > 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) { > + 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 *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 *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