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
| ||
|
Message-ID: <CAHsH6GtmOjHK-504JSvGeTLxct3JQjzDGq5nr9GO8fm=pjmU-A@mail.gmail.com> Date: Sun, 10 Dec 2023 11:14:25 -0800 From: Eyal Birger <eyal.birger@...il.com> To: Michael Richardson <mcr@...delman.ca> Cc: davem@...emloft.net, dsahern@...nel.org, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, steffen.klassert@...unet.com, herbert@...dor.apana.org.au, pablo@...filter.org, paul@...ats.ca, nharold@...gle.com, devel@...ux-ipsec.org, netdev@...r.kernel.org Subject: Re: [devel-ipsec] [PATCH ipsec-next, v2] xfrm: support sending NAT keepalives in ESP in UDP states Hi Michael, On Sun, Dec 10, 2023 at 10:47 AM Michael Richardson <mcr@...delman.ca> wrote: > > > + BUILD_BUG_ON(XFRMA_MAX != XFRMA_NAT_KEEPALIVE_INTERVAL); > > This code was there before, and you are just updating it, but I gotta wonder > about it. It feels very not-DRY. > It seems to be testing that XFRMA_MAX was updated correctly in the header > file, and I guess I'm dubious about where it is being done. > > I said last year at the workshop that I'd start a tree on documentation for > XFRM stuff, and I've managed to actually start that, and I'll attempt to use > this new addition as template. I'd definitely appreciate any documentation merged into the code. > > As a general comment, until this work is RCU'ed I'm wondering how it will > perform on systems with thousands of SAs. As you say: this is a place for > improvement. If no keepalives are set, does the code need to walk the xfrm > states at all. I wonder if that might mitigate the situation for bigger > systems that have not yet adapted. I don't see a way to not include this > code. The work isn't scheduled unless there are states with a defined interval, so afaict this shouldn't affect systems not using this feature. Or maybe I didn't understand your point? Thanks, Eyal.
Powered by blists - more mailing lists