Re: [PATCH v4] nvmet: add cgroup_path to charge namespace I/O to a cgroup
From: Tejun Heo
Date: Thu Sep 24 2026 - 02:14:23 EST
Hello,
On Wed, Sep 23, 2026 at 10:31:21PM -0700, Peng Yu wrote:
...
> +#ifdef CONFIG_BLK_CGROUP
> +static int nvmet_blkcg_ns_enable(struct nvmet_ns *ns)
> +{
...
> + cgrp = cgroup_get_from_id(ns->cgroup_id);
> + if (IS_ERR(cgrp)) {
> + pr_err("failed to resolve cgroup id %llu: %ld\n",
> + ns->cgroup_id, PTR_ERR(cgrp));
> + return PTR_ERR(cgrp);
> + }
> +
> + css = cgroup_get_e_css(cgrp, &io_cgrp_subsys);
> + if (!css || css->cgroup != cgrp) {
> + pr_err("the io controller is not enabled in cgroup %llu\n",
> + ns->cgroup_id);
> + if (css)
> + css_put(css);
> + cgroup_put(cgrp);
> + return -EINVAL;
> + }
> + ns->blkcg_css = css;
This is really odd from interface POV. The user specified "associate IOs to
this cgroup" and that can fail if blkcg is not enabled on the cgroup. Even
if it succeeds, if blkcg gets disabled and re-enabled on the cgroup, the
device is still going to be issuing IOs as the old draining blkcg.
What the user can express is the target cgroup and the IOs should follow
whatever IO control that specified cgroup is under at the time of each IO
issue. Currently, cgroup_e_css() has to walk up the tree to find the
effective css for a given subsystem but updating cgroup code to add e_css[]
array on each cgroup to avoid the overhead shouldn't be too difficult.
Thanks.
--
tejun