netdev - Re: [PATCH ipsec-next 2/3] xfrm: interface: Add unstable helpers for setting/getting XFRM metadata from TC-BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <953fb82c-0871-748e-e0f0-6ecca6ec80ee@linux.dev>
Date:   Wed, 30 Nov 2022 11:10:13 -0800
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     Eyal Birger <eyal.birger@...il.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, linux-kselftest@...r.kernel.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        herbert@...dor.apana.org.au, andrii@...nel.org,
        daniel@...earbox.net, nicolas.dichtel@...nd.com,
        razor@...ckwall.org, mykolal@...com, ast@...nel.org,
        song@...nel.org, yhs@...com, john.fastabend@...il.com,
        kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com,
        jolsa@...nel.org, shuah@...nel.org,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH ipsec-next 2/3] xfrm: interface: Add unstable helpers for
 setting/getting XFRM metadata from TC-BPF

On 11/29/22 8:15 AM, Jakub Kicinski wrote:
> On Tue, 29 Nov 2022 10:50:01 +0100 Steffen Klassert wrote:
>>> Please tag for bpf-next
>>
>> This is a change to xfrm ipsec, so it should go
>> through the ipsec-next tree, unless there is
>> a good reason for handling that different.

The set is mostly depending on the bpf features.  Patch 2 is mostly depending on 
bpf and patch 3 is also a bpf selftest.  I assume the set should have been 
developed based on the bpf-next tree instead.  It is also good to have the test 
run in bpf CI sooner than later to bar on-going bpf changes that may break it. 
It is the reason I think bpf-next makes more sense.

If it is preferred to go through ipsec-next, the set should at least be tested 
against the bpf-next before posting.

https://patchwork.kernel.org/project/netdevbpf/patch/20221129132018.985887-4-eyal.birger@gmail.com/