On 9/4/26 7:44 PM, Ilya Maximets wrote: > Conntrack flush supports filtering by zone using CTA_ZONE, but this > attribute is really hard to use from user space applications. The > reason is that it is not possible to tell if it's supported or not. > > Older kernels silently ignore CTA_ZONE. And in that case they just > happily flush all the entries from all zones breaking all the existing > connections. So, applications have to infer support from the kernel > version. While it works in most cases, it's not a particularly > reliable or desired way to check kernel capabilities from applications > that aim to be portable. There should be a better way to probe or > discover features in the kernel. > > The CTA_FILTER interface on the other hand is simple enough to probe. > We can check for NLM_F_DUMP_FILTERED in the dump to see if filtering > is supported. And unknown sub-attributes in CTA_FILTER are rejected > explicitly since strict validation is in use there. > > Let's add new CTA_FILTER_ZONE that signals that CTA_ZONE should be > filtered on. It is a flag, since everything in the CTA_FILTER is a > bit mask, i.e., a form of a flag. If set, it means that CTA_ZONE must > be present and be used for filtering. If the flag is not set however, > the filtering on CTA_ZONE will still take place to ensure backwards > compatibility. So, the flag doesn't really change the filtering > behavior, but it allows user space applications to properly discover > support for CTA_ZONE filtering without need to rely on kernel version > parsing or risk accidental flushes of the entire conntrack table, > and also without modifying the kernel state. > > A new test variant is added to test with and without the new flag. > Since the setup code is moved into a shared function, expectations > replaced with assertions to bail early if the base setup fails to > avoid the cascade of secondary failures that can be misleading. > Error return is only for the SKIP cases. > > Signed-off-by: Ilya Maximets <[email protected]> > --- CI reported a build failure for the selftest. It is caused by this issue: https://lore.kernel.org/r/[email protected]
Not related to the patch itself. Best regards, Ilya Maximets.
