BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kaitao Cheng" <kaitao.cheng@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [RFC v3 2/3] tools/ufq_iosched: add BPF example scheduler and build scaffolding
Date: Sat, 03 Oct 2026 04:44:32 +0000	[thread overview]
Message-ID: <20261003044433.059B01F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261003042748.33795-2-kaitao.cheng@linux.dev>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ufq_iosched: bpf_rbtree_left() returns structural child missing logical predecessor
--

commit 64af8341d2a8ec597c3320deffd60d7e970c5a0d
Author: Kaitao Cheng <chengkaitao@kylinos.cn>
Subject: tools/ufq_iosched: add BPF example scheduler and build scaffolding

Add ufq_iosched as a simple example for the UFQ block I/O scheduler. In the
ufq_simple example, we implement the eBPF struct_ops hooks the kernel exposes so
we can exercise and validate the behavior and stability of the kernel UFQ
scheduling framework.

diff --git a/tools/ufq_iosched/ufq_simple.bpf.c b/tools/ufq_iosched/ufq_simple.bpf.c
new file mode 100644
index 0000000000000..f49ef0d192588
--- /dev/null
+++ b/tools/ufq_iosched/ufq_simple.bpf.c
[ ... ]
> +static struct request *merge_bio_left_unlock(struct ufq_simple_data *ufq_sd,
> +					     struct bpf_rb_root *tree,
> +					     struct sort_tree_node *snode,
> +					     struct request *cand)
> +{
> +	struct sort_tree_node *left_node = NULL, *owned;
> +	sector_t cand_start, left_start, left_end;
> +	struct bpf_rb_node *tmp, *removed = NULL;
> +	struct request *left_rq = NULL;
> +	bool merged = false;
> +
> +	cand_start = cand->__sector;
> +	tmp = bpf_rbtree_left(tree, &snode->rb_node);
> +	if (!tmp)
> +		goto end;
> +
> +	left_node = container_of(tmp, struct sort_tree_node, rb_node);

[Severity: Medium]
Will bpf_rbtree_left() return the structural left child of the RB-tree node
instead of the logically adjacent predecessor in the sorted order?

If the logical predecessor is an ancestor or the rightmost node of the left
subtree, will this structural check test the wrong node and miss valid double
merge opportunities for I/O requests?

[ ... ]
> +static struct request *merge_bio_right_unlock(struct ufq_simple_data *ufq_sd,
> +					      struct bpf_rb_root *tree,
> +					      struct sort_tree_node *snode,
> +					      struct request *cand)
> +{
> +	struct bpf_rb_node *right_rb, *removed = NULL;
> +	struct sort_tree_node *right_node = NULL;
> +	struct request *right_rq = NULL;
> +	sector_t cand_end, right_start;
> +	bool merged = false;
> +
> +	cand_end = cand->__sector + (cand->__data_len >> SECTOR_SHIFT);
> +
> +	right_rb = bpf_rbtree_right(tree, &snode->rb_node);
> +	if (!right_rb)
> +		goto end;
> +
> +	right_node = container_of(right_rb, struct sort_tree_node, rb_node);

[Severity: Medium]
Does bpf_rbtree_right() return the structural right child instead of the
logically adjacent successor?

Similar to the left check above, will this structural check bypass valid
double merge opportunities when the logical successor is not the direct
right child?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003042748.33795-1-kaitao.cheng@linux.dev?part=2

  reply	other threads:[~2026-10-03  4:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03  4:27 [RFC v3 0/3] block: Introduce a BPF-based I/O scheduler Kaitao Cheng
2026-10-03  4:27 ` [RFC v3 2/3] tools/ufq_iosched: add BPF example scheduler and build scaffolding Kaitao Cheng
2026-10-03  4:44   ` sashiko-bot [this message]
2026-10-03  4:27 ` [RFC v3 1/3] block: Introduce the UFQ I/O scheduler Kaitao Cheng
2026-10-03  4:45   ` sashiko-bot
2026-10-03  4:27 ` [RFC v3 3/3] tools/ufq_iosched: add PFQ eBPF " Kaitao Cheng
2026-10-03  4:42   ` sashiko-bot
2026-10-03  9:36 ` [RFC v3 0/3] block: Introduce a BPF-based " Alexei Starovoitov
2026-10-03 11:15   ` Kaitao Cheng

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=20261003044433.059B01F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kaitao.cheng@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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