Re: Performance issue due to constant "modprobes"

[Ed W <lists@wildgooses.com>]

>> It may well be the case that it's the kernel which is running the code
>> in xtables.c.
> 
> No no no. Not unless you run a hack like Kernel Mode Linux, which I
> doubt you do. Or do you? I have no idea what grsec put into their
> stuff, or whether you have an authentic unpatched iptables program.
> It does not look standard at all.

Nope, normal 2.6.37 kernel with grsec patches.  iptables 1.4.10 is
compiled under gentoo and largely vanilla other than I have added the
commit from Maciej and my own hack to delete modprobing

I think grsec is relatively unexciting in this case - largely it's just
a big "constifying" patch, plus some RBAC features.  If you strip out
the "constify" stuff (and chroot limitations), the remaining patch is
reasonably small and sane.


>> $ cat /tmp/modp.log
>> ip_tables -q
>> -q -- ipt_SET
>> -q -- ipt_SET
>> -q -- ipt_set
>> -q -- ipt_set
> 
> The trailing -q is a hint towards the call from iptables, whereas the
> leading -q is kernel-invoked calls. Specifically, it seems that
> xt_set is indeed not built-in, but a module.

Hmm, that's an interesting point.

So ipt_SET of course not build in to the kernel (2.6.37/38).  Further I
can't find any reference to it in a 2.6.38 kernel tree? I do however see
something in the 2.6.39-rc3 tree (sanity check please - is this correct?)

This would seem to explain why the kernel autoloader was having a try to
find some missing module? It's actually completely missing on this kernel?


However, I really don't understand the sequence of calls here that has
caused apparently a "modprobe iptables" from xtables.c to trigger the
kernel (?) to try and insert some module that it knows nothing about
(only iptables seems to know about it)?

Hmm, not sure how to progress this now?

Ed W