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: <ZTJ2iKk3sBFzVQJl@yury-ThinkPad> Date: Fri, 20 Oct 2023 05:46:00 -0700 From: Yury Norov <yury.norov@...il.com> To: Alexander Lobakin <aleksander.lobakin@...el.com> Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Rasmus Villemoes <linux@...musvillemoes.dk>, Alexander Potapenko <glider@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, David Ahern <dsahern@...nel.org>, Przemek Kitszel <przemyslaw.kitszel@...el.com>, Simon Horman <simon.horman@...igine.com>, netdev@...r.kernel.org, Stephen Rothwell <sfr@...b.auug.org.au>, linux-btrfs@...r.kernel.org, dm-devel@...hat.com, ntfs3@...ts.linux.dev, linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 00/13] ip_tunnel: convert __be16 tunnel flags to bitmaps + Stephen On Mon, Oct 16, 2023 at 10:55:02AM -0700, Yury Norov wrote: > On Mon, Oct 16, 2023 at 06:52:34PM +0200, Alexander Lobakin wrote: > > Based on top of "Implement MTE tag compression for swapped pages"[0] > > from Alexander Potapenko as it uses its bitmap_{read,write}() functions > > to not introduce another pair of similar ones. > > > > Derived from the PFCP support series[1] as this grew bigger (2 -> 13 > > commits) and involved more core bitmap changes. Only commits 10 and 11 > > are from the mentioned tree, the rest is new. PFCP itself still depends > > on this series. > > > > IP tunnels have their flags defined as `__be16`, including UAPI, and > > after GTP was accepted, there are no more free bits left. UAPI (incl. > > direct usage of one of the user structs) and explicit Endianness only > > complicate things. > > Since it would either way end up with hundreds of locs due to all that, > > pick bitmaps right from the start to store the flags in the most native > > and scalable format with rich API. I don't think it's worth trying to > > praise luck and pick smth like u32 only to redo everything in x years :) > > More details regarding the IP tunnel flags is in 11 and 13. > > > > The rest is just a good bunch of prereqs and tests: a couple of new > > helpers and extensions to the old ones, a few optimizations to partially > > mitigate IP tunnel object code growth due to __be16 -> long, and > > decouping one UAPI struct used throughout the whole kernel into the > > userspace and the kernel space counterparts to eliminate the dependency. > > > > [0] https://lore.kernel.org/lkml/20231011172836.2579017-1-glider@google.com > > [1] https://lore.kernel.org/netdev/20230721071532.613888-1-marcin.szycik@linux.intel.com [...] > > --- > > Not sure whether it's fine to have that all in one series, but OTOH > > there's not much stuff I could split (like, 3 commits), it either > > depends directly (new helpers etc.) or will just generate suboptimal > > code w/o some of the commits. > > > > I'm also thinking of which tree this would ideally be taken through. > > The main subject is networking, but most of the commits are generic. > > My idea is to push this via Yury / bitmaps and then ask the netdev > > maintainers to pull his tree before they take PFCP (dependent on this > > one). > > Let's wait for more comments, but I'm generally OK with the generic > part, and have nothing against moving it, or the whole series, through > bitmap-for-next. I put this into bitmap-for-next, and it caused build failures for Stephen: https://lore.kernel.org/lkml/20220722191657.1d7282c2@canb.auug.org.au/ I can reproduce them too. So, removing from -next. Alexander, can you run another round with all found issues fixed? Thanks, Yury
Powered by blists - more mailing lists