> diff --git a/net/core/filter.c b/net/core/filter.c
> index 6e345ca65ca1..643411e292ce 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
[ ... ]
> @@ -2792,8 +2833,10 @@ static const struct bpf_func_proto
> bpf_msg_pull_data_proto = {
> BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, u32, start,
> u32, len, u64, flags)
> {
> + bool sge_copy = false, nsge_copy = false, nnsge_copy = false;
> struct scatterlist sge, nsge, nnsge, rsge = {0}, *psge;
> u32 new, i = 0, l = 0, space, copy = 0, offset = 0;
> + bool rsge_copy = false;
> u8 *raw, *to, *from;
> struct page *page;
The netdev reverse xmas tree convention orders declarations longest to
shortest (Documentation/process/maintainer-netdev.rst). Here the new
"bool rsge_copy = false;" sits below the shorter "u32 new, ..." line.
Should rsge_copy move up with the other bool declarations?
[ ... ]
> @@ -3027,8 +3098,10 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg,
> u32, start,
> */
> if (start != offset) {
> struct scatterlist *nsge, *sge = sk_msg_elem(msg, i);
> + bool sge_copy = sk_msg_elem_is_copy(msg, i);
> int a = start - offset;
> int b = sge->length - pop - a;
> + u32 sge_idx = i;
The same ordering question applies here. The new "bool sge_copy" and
"u32 sge_idx" are interleaved with the shorter "int a" / "int b"
declarations rather than sorted longest to shortest. Should these be
reordered to follow the reverse xmas tree style?
---
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/27418314509