Re: [PATCH bpf-next v3 0/2] bpf: support setting max RTO for bpf_setsockopt

[Daniel Xu <dlxu@meta.com>]

Hi Jason,

On 2/19/25 12:44 AM, Jason Xing wrote:
> On Wed, Feb 19, 2025 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
>> Dear patch submitter,
>>
>> CI has tested the following submission:
>> Status:     FAILURE
>> Name:       [bpf-next,v3,0/2] bpf: support setting max RTO for bpf_setsockopt
>> Patchwork:  https://patchwork.kernel.org/project/netdevbpf/list/?series=935463&state=*
>> Matrix:     https://github.com/kernel-patches/bpf/actions/runs/13408235954
>>
>> Failed jobs:
>> build-aarch64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248960
>> build-s390x-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452248633
>> build-x86_64-gcc: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452249287
>> build-x86_64-llvm-17: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250339
>> build-x86_64-llvm-17-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452250688
>> build-x86_64-llvm-18: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251018
>> build-x86_64-llvm-18-O2: https://github.com/kernel-patches/bpf/actions/runs/13408235954/job/37452251311
>>
>>
>> Please note: this email is coming from an unmonitored mailbox. If you have
>> questions or feedback, please reach out to the Meta Kernel CI team at
>> kernel-ci@meta.com.
> I think the only diff I made is that I removed the change in
> tools/include/uapi/linux/bpf.h from V2.
> diff --git a/tools/include/uapi/linux/tcp.h b/tools/include/uapi/linux/tcp.h
> index 13ceeb395eb8..7989e3f34a58 100644
> --- a/tools/include/uapi/linux/tcp.h
> +++ b/tools/include/uapi/linux/tcp.h
> @@ -128,6 +128,7 @@ enum {
>   #define TCP_CM_INQ             TCP_INQ
>
>   #define TCP_TX_DELAY           37      /* delay outgoing packets by XX usec */
> +#define TCP_RTO_MAX_MS         44      /* max rto time in ms */
>
> Last time everything was fine. I doubt it has something to do with the
> failure :S
>
> But I tested it locally and could not reproduce it. Could it be caused
> because of applying to a wrong branch? I'm afraid not, right?

It looks like TCP_RTO_MAX_MS is defined in include/uapi/linux/tcp.h. But

I don't see a uapi include in net/core/filter.c where you're using the 
definition.


Given the transitive dependency, perhaps some other file shifted? Seems 
better

to directly include the uapi header if you're going to use it.


Thanks,

Daniel