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: <4ed81222-9409-4c9b-bd29-dbaf4275984f@app.fastmail.com> Date: Wed, 04 Oct 2023 10:25:03 +0200 From: "Arnd Bergmann" <arnd@...db.de> To: "Jakub Kicinski" <kuba@...nel.org>, "Anthony L Nguyen" <anthony.l.nguyen@...el.com> Cc: "Arnd Bergmann" <arnd@...nel.org>, "Jesse Brandeburg" <jesse.brandeburg@...el.com>, "Lobakin, Alexandr" <alexandr.lobakin@...el.com>, "David S . Miller" <davem@...emloft.net>, "Eric Dumazet" <edumazet@...gle.com>, "Paolo Abeni" <pabeni@...hat.com>, "Alan Brady" <alan.brady@...el.com>, "Sridhar Samudrala" <sridhar.samudrala@...el.com>, "Willem de Bruijn" <willemb@...gle.com>, "Phani Burra" <phani.r.burra@...el.com>, "Joshua A Hay" <joshua.a.hay@...el.com>, "Pavan Kumar Linga" <pavan.kumar.linga@...el.com>, "Madhu Chittim" <madhu.chittim@...el.com>, "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>, Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org, "Alexander Lobakin" <aleksander.lobakin@...el.com> Subject: Re: [PATCH] idpf: fix building without IPv4 On Wed, Oct 4, 2023, at 00:43, Jakub Kicinski wrote: > On Mon, 25 Sep 2023 10:05:03 -0700 Tony Nguyen wrote: >> Also, a pending patch for this [1], however, this does look a bit more >> efficient. Adding Olek as he's author on the other patch. >> >> netdev maintainers, >> >> If this is the version that does get picked up, did you want to take it >> directly to close out the compile issues? > > Sorry for the delays. Should we not add a !INET static inline wrapper > for tcp_gro_complete()? Seems a bit backwards to me to make drivers > suffer and think about such a preposterous config :S > > $ git grep tcp_gro_complete -- drivers/ > drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c: tcp_gro_complete(skb); > drivers/net/ethernet/broadcom/bnxt/bnxt.c: tcp_gro_complete(skb); > drivers/net/ethernet/intel/idpf/idpf_txrx.c: tcp_gro_complete(skb); > drivers/net/ethernet/qlogic/qede/qede_fp.c: tcp_gro_complete(skb); > > We have 4 drivers which need ifdefs already and the number will only > grow with GRO-HW spreading. That sounds good to me, but it's better if someone that understands this code patch better than me writes the stub helpers, to ensure all callers have sensible behavior in that configuration. I also had a brief look at who might be using kernels without CONFIG_INET. In the kernel source tree, there are 19 defconfig files that completely enable CONFIG_NET, which means that both INET and ETHERNET are always turned off as well. There are four configs that enable CONFIG_NET but not CONFIG_INET: arch/arm/configs/spear3xx_defconfig arch/arm/configs/spear6xx_defconfig arch/m68k/configs/virt_defconfig arch/s390/configs/zfcpdump_defconfig I'm confident that the two arm configs are a mistake, as these are regular embedded SoCs with on-chip ethernet that is enabled in the config but almost certainly has no other use. The virt defconfig lost CONFIG_INET after commit d7385ba13771 ("9p: Remove INET dependency") added an 'imply INET'. This sounds like a bad idea, since it messes up the 'defconfig' logic when a leaf driver enables an entire subsystem. The s390 zfcpdump defconfig looks like a legitimate case for disabling INET, but it's not that size constrained and it might not actually need CONFIG_NET either. So overall, it seems there is no real need to support CONFIG_NET=y with CONFIG_INET=n and we could just make them be the same and avoid bugs like this. In theory we could also go the opposite way and try to make INET a tristate symbol that can live in a loadable module like all other network protocols. This would be nice conceptually and for smaller vmlinux files (some systems are much more limited in the size of their boot partition than their RAM and rootfs), but would clearly cause way more build failures. Arnd
Powered by blists - more mailing lists