On Sat, 2005-01-22 at 23:30 +0100, Bart De Schuymer wrote:
Hi Bart
> @@ -138,23 +139,34 @@ void nf_log_packet(int pf,
> /* This is gross, but inline doesn't cut it for avoiding the function
> call in fast path: gcc doesn't inline (needs value tracking?). --RR */
> #ifdef CONFIG_NETFILTER_DEBUG
> -#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
> - nf_hook_slow((pf), (hook), (skb), (indev), (outdev), (okfn), INT_MIN)
> -#define NF_HOOK_THRESH nf_hook_slow
> +#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
> +({int __ret = 0; \
> +if (!nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN, &__ret); \
> + __ret = (okfn)(skb); \
> +__ret;})
> +#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
> +({int __ret = 0; \
> +if (!nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh, &__ret); \
> + __ret = (okfn)(skb); \
> +__ret;})
> #else
I guess you never testcompiled with CONFIG_NETFILTER_DEBUG set :)
The if-statements above needs to have ; replaced with )
> + if (verdict > NF_MAX_VERDICT) {
> + NFDEBUG("Evil return from %p(%u).\n",
> + elem->hook, hook);
> + continue;
> + }
Maybe add unlikely() around the test?
Otherwise the changes look sane.
The reoganisation of things in nf_hook_slow() shouldn't cause any
performance changes, I tried to benchmark various variations of that
code some time ago but the result of the changes were more or less in
the noise.
--
/Martin
signature.asc
Description: This is a digitally signed message part
|