On 3/11/25 11:39 AM, Martin KaFai Lau wrote:
On 3/11/25 4:07 AM, Jason Xing wrote:
On Tue, Mar 11, 2025 at 10:26 AM <bot+bpf-ci@xxxxxxxxxx> wrote:
Dear patch submitter,
CI has tested the following submission:
Status: FAILURE
Name: [bpf-next,v2,0/6] tcp: add some RTO MIN and DELACK MAX {bpf_}set/
getsockopt supports
Patchwork: https://patchwork.kernel.org/project/netdevbpf/list/?
series=942617&state=*
Matrix: https://github.com/kernel-patches/bpf/actions/runs/13784214269
Failed jobs:
test_progs-aarch64-gcc: https://github.com/kernel-patches/bpf/actions/
runs/13784214269/job/38548852334
test_progs_no_alu32-aarch64-gcc: https://github.com/kernel-patches/bpf/
actions/runs/13784214269/job/38548853075
test_progs-s390x-gcc: https://github.com/kernel-patches/bpf/actions/
runs/13784214269/job/38548829871
test_progs_no_alu32-s390x-gcc: https://github.com/kernel-patches/bpf/actions/
runs/13784214269/job/38548830246
I see https://netdev.bots.linux.dev/static/nipa/942617/apply/desc that
It cannot apply, so it applied to bpf-next/net.
I just confirmed by first checking this:
https://github.com/kernel-patches/bpf/pulls
then find your patches and figure out bpf-net_base:
https://github.com/kernel-patches/bpf/pull/8649
says the patch can not be applied. Could it be possible that CI
applied it on the wrong branch? I targeted the net branch.
I have no clue this series is affecting the following tests
The test is changing the exact same test setget_sockopt and it failed, so it
should be suspicious enough to look at the details of the bpf CI report.
The report said it failed in aarch64 and s390 but x86 seems to be fine.
When the test failed, it pretty much failed on all tests. It looks like some of
the new set/getsockopt checks failed in these two archs. A blind guess is the
jiffies part.
and forgot to mention that you can run bpf CI before posting. This may be easier
to test other archs. Take a look at Documentation/bpf/bpf_devel_QA.rst. The
section "How do I run BPF CI on my changes before sending them out for review?"
(./test_progs -t setget_sockopt). It seems it has nothing to do with
this series. And I'm unable to reproduce it locally.
