Re: Performance issue due to constant "modprobes"

["Maciej Żenczykowski" <zenczykowski@gmail.com>]

I should probably point out that iptables module autoloading behaviour
is very different for a pre-my commit statically compiled, non-shared
iptables binary
vs a post-my commit or non-statically compiled binary.

The modprobe issue would only show up if you had a statically
compiled, non-shared iptables binary.
ie. one where all the extensions were already part of the iptables
binary and would always get initialized at startup (even for iptables
-h).

Basically the problem is when we're doing revision compatibility
testing as part of an extensions init sequence we will modprobe from
userspace.
I believe we always attempt a module load there instead of first
checking for api existence, and modprobing if the API is missing.

The fix would probably be in xtables.c in compatible_revision() to
change everything starting with:
  xtables_load_ko(xtables_modprobe_program, true);
into a for loop:

something along the lines of

for (int load = 0; load <= 1; ++load) {
  if (load) xtables_load_ko(...);

  ...

  and replace "close(sockfd); return 0;" with "if (load) {
close(sockfd); return 0; }; continue;"

I'll try to write up and maybe even test a real patch tomorrow.

- Maciej