The Xtables-addons compat layer does not support pskb relocation
(result of possible memory allocation in kernels before 2.6.24) and
we just assume it does not happen. Add a check to warn if relocation
did happen and packet loss is to be expected.
The old database format was in unknown byteorder -- if you run the
converter program yourself, you got a host order file, but if you
downloaded the preprocessed DB file (geoipdb.bin), you got a
little-endian file.
Use a new database format. Instead of having an index and a DB file,
do away with the index and let the filesystem do the indexing, using
one file per country. Also access the database files with a known
endianess type. The converter script now produces two distinct
variants (especially needed for IA-64).
All of this reduces the touched code by half.
For the header file, we need __u32 and so on because they are exported
to userspace and rather constitute a kernel header.
Use normal types instead of uintXX_t in the main code.
spin_lock_bh does not look safe (only disables preempt on current
CPU?). Change to spin_lock, that also avoids the management overhead
of spin_lock_bh. to spin_lock to avoid management overhead.
Use rcu in match and destroy function.
A 64-bit kernel will interpret the pointer with 64 bits width, while
a 32-bit userspace filled in only 32 of it, leaving the other 32
undefined. This must be avoided.
The subnet list may become really large (United States: ~15000
entries), which means a use of roughly 120 KB, and kmalloc may fail
to find a contiguous block in physical memory. Virtual contiguity is
enough, so use vmalloc/vfree.
vfree may not be called within a spin_lock_bh area, so release the
lock first, it is safe to do so.
Certain countries have lots (around 10000) of IP address ranges
(US,GB,DE,...). The current linear search is really bad:
No firewall:
3000 packets transmitted, 3000 received, 0% packet loss, time 1992ms
Testing against the countries with top 50 IP ranges:
3000 packets transmitted, 3000 received, 0% packet loss, time 8998ms
With binary search:
3000 packets transmitted, 3000 received, 0% packet loss, time 2358ms
find_node: The reference count needs to be increased while the lock
is held. Otherwise, the node may disappear right after the lock was
released and increase was attempted, leading to an oops.
remove_node: The reference count needs to be checked while the lock
is held. Otherwise, the node may be used in the match function or
returned from find_node while it has a zero refcount.
