Re: [RFC v2 3/3] tools/ufq_iosched: add BPF example scheduler and build scaffolding
From: bot+bpf-ci
Date: Sun May 03 2026 - 00:46:03 EST
> diff --git a/tools/ufq_iosched/ufq_simple.bpf.c b/tools/ufq_iosched/ufq_simple.bpf.c
> new file mode 100644
> index 000000000000..81954e73068a
> --- /dev/null
> +++ b/tools/ufq_iosched/ufq_simple.bpf.c
[ ... ]
> +int BPF_STRUCT_OPS(ufq_simple_insert_req, struct request_queue *q,
> + struct request *rq, blk_insert_t flags,
> + struct list_head *freeq)
^^^^^^^
Does this signature match the kernel's ufq_iosched_ops definition?
Looking at block/ufq-iosched.h, the insert_req member is defined with
three parameters:
int (*insert_req)(struct request_queue *q, struct request *rq,
blk_insert_t flags);
The kernel-side callers in block/ufq-iosched.c also pass only three
arguments:
ret = ops->insert_req(q, rq, flags);
ops->insert_req(q, target, 0);
The BPF struct_ops verifier (check_struct_ops_btf_id) validates that each
BPF program matches the declared function-pointer signature in the kernel.
A program with four parameters registered against a three-parameter member
will be rejected at load time, so ufq_simple will fail to attach via
UFQ_OPS_LOAD / UFQ_OPS_ATTACH and the example cannot be used.
Even if the verifier accepted the mismatch, the trampoline would not
populate a fourth argument, leaving freeq uninitialized. Should the extra
'struct list_head *freeq' parameter be removed?
> +{
> + struct ufq_simple_data *ufq_sd;
> + struct queue_list_node *qnode;
> + struct sort_tree_node *snode;
[ ... ]
> +UFQ_OPS_DEFINE(ufq_simple_ops,
> + .init_sched = (void *)ufq_simple_init_sched,
> + .exit_sched = (void *)ufq_simple_exit_sched,
> + .insert_req = (void *)ufq_simple_insert_req,
> + .dispatch_req = (void *)ufq_simple_dispatch_req,
> + .has_req = (void *)ufq_simple_has_req,
> + .finish_req = (void *)ufq_simple_finish_req,
> + .merge_req = (void *)ufq_simple_merge_req,
> + .merge_bio = (void *)ufq_simple_merge_bio,
> + .name = "ufq_simple");
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25269522212