From: Tejun Heo <tj@kernel.org>
To: Tao Cui <cui.tao@linux.dev>
Cc: josef@toxicopanda.com, axboe@kernel.dk, cgroups@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, andrii@kernel.org, eddyz87@gmail.com,
ast@kernel.org, daniel@iogearbox.net,
linux-kselftest@vger.kernel.org, cuitao@kylinos.cn,
ameryhung@gmail.com, alexei.starovoitov@gmail.com
Subject: Re: [PATCH 2/5] blk-iocost: add BPF struct_ops cost model support
Date: Wed, 28 Oct 2026 10:09:28 -1000 [thread overview]
Message-ID: <0753eaa990c954aa56a0c5fa8ba302e2@kernel.org> (raw)
In-Reply-To: <20261028143534.135968-3-cui.tao@linux.dev>
Hello, Tao.
On Wed, Oct 28, 2026 at 10:35:31PM +0800, Tao Cui wrote:
> +/*
> +/*
> + * Deliver iocg_init()/iocg_free() to the cgroups already online on the
The comment opens with "/*" twice. clang warns "'/*' within block comment
[-Wcomment]" and CONFIG_WERROR builds break.
> + /*
> + * A blkg which never went online never reached the
> + * radix tree, so it must not receive an init either;
> ...
> + if (!iocg || !iocg->pd.online)
> + continue;
blkg_create() adds a blkg to q->blkg_list only after radix_tree_insert()
succeeds, so the blkgs skipped here are the ones blkg_destroy() already
took offline, not ones that never reached the radix tree.
> + if (!disk_live(disk)) {
> + mutex_unlock(&q->rq_qos_mutex);
> + blk_mq_unfreeze_queue(q, memflags);
> + blkdev_put_no_open(bdev);
> + return -ENODEV;
> + }
The guard() suggestion from v10 was only partly applied. This unlock,
unfreeze and put sequence is repeated on three error paths.
> + /*
> + * Scope the mutex so the tail bdev put runs with blkcg_mutex
> + * already released: dropping the last device reference can
> + * reach disk_release() -> blkcg_exit_disk() ->
> + * blkg_destroy_all(), which takes q->blkcg_mutex.
> + */
> + {
> + guard(mutex)(&q->blkcg_mutex);
The bare { } block isn't necessary, and ioc_bpf_detach() has the same
block with the same comment. Can you drop them?
> + /*
> + * The attachment is checked under rq_qos_mutex first, so an unmatched
> + * detach exits without freezing.
> + */
> + mutex_lock(&q->rq_qos_mutex);
> + spin_lock_irq(&q->queue_lock);
> + ioc = q_to_ioc(q);
> + if (ioc) {
> + spin_lock(&ioc->lock);
> + matched = ioc_attached_model_locked(ioc) == ops &&
> + ioc->bpf_link == link;
> ...
The same 11 lines check the attachment again after the freeze. The check
under rq_qos_mutex after the freeze is the one that matters.
> +/*
> + * Pluggable cost model interface for blk-iocost.
> + *
> + * A BPF struct_ops implementation can take over the cost model of one device.
> ...
> + * offline and its free. Both callbacks are called with ioc->lock held and must
> + * not sleep; the delivery points nest inside queue_lock except for iocg_free()
> + * from ioc_pd_free() in blkg_free_workfn().
> + */
This restates the attach mechanics and lists the call sites. The comments
and descriptions in general are still long and narrate mechanics.
Thanks.
--
tejun
next prev parent reply other threads:[~2026-10-28 20:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 14:35 [RFC PATCH v11 0/5] blk-iocost: BPF struct_ops cost model Tao Cui
2026-10-28 14:35 ` [PATCH 1/5] blk-iocost: move shared definitions to blk-iocost.h Tao Cui
2026-10-28 20:09 ` Tejun Heo
2026-10-28 14:35 ` [PATCH 2/5] blk-iocost: add BPF struct_ops cost model support Tao Cui
2026-10-28 15:33 ` bot+bpf-ci
2026-10-28 20:09 ` Tejun Heo [this message]
2026-10-28 14:35 ` [PATCH 3/5] selftests/bpf: add iocost cost model test Tao Cui
2026-10-28 15:33 ` bot+bpf-ci
2026-10-28 20:09 ` Tejun Heo
2026-10-28 14:35 ` [PATCH 4/5] blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary Tao Cui
2026-10-28 20:09 ` Tejun Heo
2026-10-28 14:35 ` [PATCH 5/5] docs: cgroup-v2: document the iocost BPF cost model attachment Tao Cui
2026-10-28 20:09 ` Tejun Heo
2026-10-28 15:58 ` [RFC PATCH v11 0/5] blk-iocost: BPF struct_ops cost model Alexei Starovoitov
2026-10-28 20:09 ` Tejun Heo
2026-10-28 20:09 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0753eaa990c954aa56a0c5fa8ba302e2@kernel.org \
--to=tj@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=josef@toxicopanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox