> diff --git a/kernel/bpf/wakeup_source_iter.c b/kernel/bpf/wakeup_source_iter.c
> --- /dev/null
> +++ b/kernel/bpf/wakeup_source_iter.c
[ ... ]
> +static void wakeup_source_iter_seq_stop(struct seq_file *seq, void *v)
> +{
> + int *srcuidx = seq->private;
> +
> + if (*srcuidx >= 0)
> + wakeup_sources_read_unlock(*srcuidx);
> + *srcuidx = -1;
> +}
Should wakeup_source_iter_seq_stop() call
__wakeup_source_seq_show(seq, v, true) when v is NULL, before
releasing the SRCU lock?
bpf_seq_read() in kernel/bpf/bpf_iter.c has this at the stop
label:
/* bpf program called if !p */
seq->op->stop(seq, p);
The other BPF iterators follow this contract:
bpf_map_seq_stop():
if (!v)
(void)__bpf_map_seq_show(seq, v, true);
task_seq_stop():
if (!v)
(void)__task_seq_show(seq, v, true);
The same pattern appears in bpf_prog_seq_stop(),
bpf_link_seq_stop(), task_file_seq_stop(), and
task_vma_seq_stop().
Without the in_stop callback, BPF programs attached to this
iterator cannot detect when iteration has finished, which
prevents finalization such as outputting aggregated results.
The __wakeup_source_seq_show() function already accepts the
in_stop parameter but is never called with true:
> +static int __wakeup_source_seq_show(struct seq_file *seq, void *v, bool
> in_stop)
> +{
[ ... ]
> + struct bpf_prog *prog = bpf_iter_get_info(&meta, in_stop);
[ ... ]
> +}
---
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/22416722500
AI-authorship-score: low
AI-authorship-explanation: The code follows standard kernel BPF iterator
patterns with no unusual characteristics suggesting AI generation.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: Missing end-of-iteration callback is an API
consistency issue that prevents BPF programs from detecting iteration
completion, but does not cause crashes or data corruption.
