Re: Shouldn't we be using alloc_skb/kfree_skb in net/ipv4/netfilter/ipt_recent.c::ip_recent_ctrl ?

[Stephen Frost <sfrost@snowman.net>]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

* David S. Miller (davem@davemloft.net) wrote:
> It's using it to send a dummy packet to the patch function.
> It is gross, but it does work because it allocated it's own
> private data area to skb->nh.iph.

Seriously doubt ipt_recent is alone in that given I based the module off
an existing netfilter module and I'm pretty confident I didn't change
anything with regard to that aspect.

> Just leave it alone for now, ipt_recent is gross and full of many
> errors and bug, and thus stands to have a rewrite. Patrick McHardy
> said he will try to do that.

Ideally it should probably be rolled into the new ippool/ipset
framework, if it's capable of supporting what ipt_recent currently does.
I had heard vaugue claims that the new framework was supposted to be
able to support something like ipt_recent but I havn't looked into it
personally.

I'm mildly curious what the issues you have with it are but I've got
nothing against someone rewriting it as long as the functionality
remains the same.  It'd be nice to have a simpler module (perhaps the
new ippool stuff does this already, not sure) which just has a
hash-based table of IPs to match against since I know alot of people use
ipt_recent for that.  It'd also be nice to be able to do ranges and jump
to specific chains based on a hash-lookup to an IP/range.

	Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]