On 04/09/2026 20:06, Ilya Maximets wrote: > 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.
Mmh, my patch didn't get picked up in the tests because the Clang build failed with Rust programs. Not sure why it got that with my patch, nor why your patch didn't hit the same issue :) Cheers, Matt -- Sponsored by the NGI0 Core fund.
