Re: [PATCH v1 bpf-next/net 5/5] selftest: bpf: Add test for hwtstamp proxy.

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Thu Jun 11, 2026 at 11:03 PM PDT, Kuniyuki Iwashima wrote:
> On Thu, Jun 11, 2026 at 5:31 PM <sashiko-bot@kernel.org> wrote:
>>
>> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
>> - [High] Comparing a potentially negative return value to `sizeof()` causes failure handling to be skipped, erroneously dropping packets.
>> - [Medium] Incorrect struct cast for SO_TIMESTAMPING_NEW cmsg data causes test failures on 32-bit systems.
>> - [Medium] Typo in the test assertion prevents verification of TX timestamp keys.
>> - [Low] Multi-line comments violate the BPF subsystem comment style.
>> - [Low] The `buf_cmsg` array is not fully initialized before being passed to `sendmsg()`, passing uninitialized stack data to the kernel.
>> --
>>
>> commit e747f30190af013f6f5cc858f0dacb86e902e2d2
>> Author: Kuniyuki Iwashima <kuniyu@google.com>
>>
>> selftest: bpf: Add test for hwtstamp proxy.
>>
>> This selftest simulates the hardware timestamp proxy scenario using two
>> UDP sockets, simulating a userspace proxy via a GENEVE device.
>>
>> > diff --git a/tools/testing/selftests/bpf/prog_tests/proxy_hwtstamp.c b/tools/testing/selftests/bpf/prog_tests/proxy_hwtstamp.c
>> > new file mode 100644
>> > index 0000000000000..d0f90f22bea22
>> > --- /dev/null
>> > +++ b/tools/testing/selftests/bpf/prog_tests/proxy_hwtstamp.c
>> [ ... ]
>> > +char *ipv4_commands[] = {
>> > +     "ip link set dev lo up",
>> > +     "ip link add geneve0 type geneve local " APP_SRC_IPV4 " external",
>> > +     "ip addr add " APP_SRC_IPV4 "/24 dev geneve0",
>> > +     "ip link set dev geneve0 address aa:bb:cc:dd:ee:ff",
>> > +     "ip link set dev geneve0 up",
>> > +     "ip route add " APP_DST_IPV4 "/32 dev geneve0",
>> > +     /* We do not forward ARP to the wire in this test,
>> > +      * so a static neighbour entry is needed for APP_DST_IPV4.
>> > +      */
>>
>> [Severity: Low]
>> Does this multi-line comment format violate the BPF subsystem comment style?
>> It seems the subsystem guidelines prefer the opening /* on its own line for
>> multi-line comments.
>
> Gray zone, this is rather net one :)

bot is correct on this one :) BPF prefers normal kernel coding style.