On 11/10/2024 17:04, Joshua Lant wrote:
Hi Kevin,
Sorry it has taken me so long to get an update on this...
No problem, my bandwidth is equally limited, doing what we can :)
Overall this is looking good to me, there are a few issues here and there (see inline replies) but I expect the next version will be in good shape to merge. Something I'd like to check before that is how you are testing these changes? I am a little concerned that patch 5 and 8 introduce clear functional regressions that presumably went unnoticed. These regressions should occur regardless of the ABI, so even netfilter tests built in the standard arm64 ABI should expose them. I see that a few netfilter kselftests exist, that may be a good start - building them for standard arm64 shouldn't be an issue (purecap is another story but this is less essential).
Kevin
My testing up to this point has been mainly on the set of 68 iptables tests (and prior to this testing using the libmnl and libnftnl tests to ensure that those packages were working correctly), testing the purecap versions of the libraries. Of these there are 3 failing tests. Two of these are due to minor issues with the diff of the expected output. One appears to be some problem setting up network namespaces that I have not had time to pursue. I am only testing the nftables tests, since I have not ported the legacy iptables.
I have got the patches ready for a V3 submission. I have been trying to get the kselftests working before submitting, but this is proving to be more of a pain than I'd imagined... The tests are running but are showing many strange errors in many places. There are problems for me getting these working in both purecap and non-purecap scenarios. The issue is that most of the tests utilize userspace packages such as iproute2, iputils and iptables, and require patching to work with updated headers.
purecap:
I have ported all of the above packages to purecap (in theory). However, some of these packages have been ported with caveats or potentially missing/broken functionality due to the need for expediency...
My primary goal in all this was to have WireGuard ported into purecap and working (passing all of it's tests). Since this is done, I have not worked further on these packages. One good exmaple of this is ping inside iputils package. It has a dependency on libgmp, which performs arbitrary precision arithmetic for some functionality. I did not want to waste my time porting this to purecap since it works for the tests that I need ping for. This could well be why many ping commands are failing in the tests, although i cannot be sure unless I spend time i dont have debugging.
This is understood - there are way too many dependencies for you to be able to test the changes comprehensively in purecap.
non-purecap:
Building and including all of these userspace packages in non-purecap, but still using the updated kernel headers and the kselftests from kernel version 6.7 is itself non-trivial. The kselftests have many commits in the past year. My build system uses Yocto, and many of the default recipes use old package versions which may need updating and patching to newer versions in order to pass these newer tests. I have seen this in several instances in my travels getting iptables tests passing. Updating has then led to other problems which required further patching...
As an example, when fixing iptables I had issues updating the kernel headers in the iptables repo, since I could not point to a non-default header location using the configure.ac in its current state. See this thread:
https://marc.info/?l=netfilter-devel&m=172304132117451&w=2
Unfortunately I dont think I have time to go down any more rabbit holes with figuring out where the issues in these tests reside (actual failure or failure due to package versions/missing features)... I have not even managed to get the perl script that runs the kselftest suite working, since I have an error about the correct perl modules not being available...
That's fair enough. I hoped that those kselftests would be reasonably easy to run, but that doesn't seem to be the case. Thanks for trying in any case. I've got a new idea that will make the changes a lot less invasive (will reply on v3), so comprehensive testing will be less essential.
Kevin
tl;dr
I do not really have time to divert my energies into getting these kselftests working. I have been testing with the iptables suite. I will submit the v3 of the patches with the changes, and you can decide if they are sufficently safe for applying.