BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tao Cui" <cui.tao@linux.dev>
Cc: tj@kernel.org, mkoutny@suse.com, hannes@cmpxchg.org, bpf@vger.kernel.org
Subject: Re: [RFC PATCH v2 4/5] selftests/bpf: add multi-stream sequentiality example model
Date: Thu, 10 Sep 2026 13:10:28 +0000	[thread overview]
Message-ID: <20260910131028.9B3A31F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910125817.223354-5-cui.tao@linux.dev>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Concurrent accesses and modifications to shared cgroup storage without synchronization.
--

commit 00d96497e1688fa01fa5b76f7ec3a10048823d74
Author: Tao Cui <cuitao@kylinos.cn>

selftests/bpf: add multi-stream sequentiality example model

This commit introduces a new example cost model for iocost using eBPF,
replacing the single-cursor sequentiality heuristic with a per-cgroup table
of stream slots. The stream state is maintained in a CGRP_STORAGE map keyed
by the cgroup.

> diff --git a/tools/testing/selftests/bpf/progs/iocost_ms.c b/tools/testing/selftests/bpf/progs/iocost_ms.c
> new file mode 100644
> index 0000000000000..3cc57c03d3c88
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/iocost_ms.c

[ ... ]

> +	now = bpf_ktime_get_ns();
> +	for (i = 0; i < NSLOTS; i++) {
> +		if (s->expected[i] == sector && s->stamp[i]) {
> +			found = i;
> +			break;
> +		}
> +	}
> +	if (found != 0xFFFFFFFF) {
> +		/* sequential: keep the seq base from the op branch */
> +		s->expected[found] = sector + advance;
> +		s->stamp[found] = now;

[Severity: Medium]
Are these lockless updates susceptible to data races? Multiple CPUs processing
IO for the same cgroup could concurrently execute iocost_ms_calc_cost() and
modify the shared cgroup storage.

Could this concurrency result in lost updates or interleaved reads and writes,
leading to inaccuracies in the sequential IO heuristic?

> +	} else {
> +		base = randio;
> +		for (i = 1; i < NSLOTS; i++) {
> +			if (s->stamp[i] < s->stamp[victim])
> +				victim = i;
> +		}
> +		s->expected[victim] = sector + advance;
> +		s->stamp[victim] = now;

[Severity: Medium]
Similarly, when claiming and updating a new stream slot, could multiple
CPUs select the same victim concurrently?

While lockless updates are often an intentional performance tradeoff in IO
hotpaths and this is an example model, could the resulting data races on the
expected and stamp arrays cause unintended behavior when tracking interleaved
streams?

> +	}
> +
> +	pages = RU(nbytes, IOC_PAGE_SIZE);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910125817.223354-1-cui.tao@linux.dev?part=4

  reply	other threads:[~2026-09-10 13:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 12:58 [RFC PATCH v2 0/5] blk-iocost: BPF struct_ops cost model Tao Cui
2026-09-10 12:58 ` [RFC PATCH v2 1/5] blk-iocost: add BPF struct_ops cost model support Tao Cui
2026-09-10 13:17   ` sashiko-bot
2026-09-10 12:58 ` [RFC PATCH v2 2/5] selftests/bpf: add iocost cost model test Tao Cui
2026-09-10 13:12   ` sashiko-bot
2026-09-10 13:46   ` bot+bpf-ci
2026-09-10 12:58 ` [RFC PATCH v2 3/5] blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary Tao Cui
2026-09-10 13:46   ` bot+bpf-ci
2026-09-10 12:58 ` [RFC PATCH v2 4/5] selftests/bpf: add multi-stream sequentiality example model Tao Cui
2026-09-10 13:10   ` sashiko-bot [this message]
2026-09-10 12:58 ` [RFC PATCH v2 5/5] docs: cgroup-v2: document io.cost model=<name> binding Tao Cui
2026-09-11  9:20 ` [RFC PATCH v2 0/5] blk-iocost: BPF struct_ops cost model Tao Cui

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=20260910131028.9B3A31F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cui.tao@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=mkoutny@suse.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tj@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