Re: [PATCH/RFC] Reduce call chain length in netfilter (was: Re: do_IRQ: stack overflow: 872..)

From: Martin Josefsson <gandalf@wlug.westbo.se>
To: Bart De Schuymer <bdschuym@pandora.be>
Cc: "David S. Miller" <davem@davemloft.net>,
	shemminger@osdl.org, dwmw2@infradead.org, ak@suse.de,
	snort2004@mail.ru, bridge@osdl.org, netdev@oss.sgi.com,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH/RFC] Reduce call chain length in netfilter (was: Re: do_IRQ: stack overflow: 872..)
Date: Sun, 23 Jan 2005 00:22:33 +0100	[thread overview]
Message-ID: <1106436153.20995.42.camel@tux.rsn.bth.se> (raw)
In-Reply-To: <1106433059.4486.11.camel@localhost.localdomain>

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]