[Top] [All Lists]

Re: do_IRQ: stack overflow: 872..

To: Bart De Schuymer <bdschuym@xxxxxxxxxx>
Subject: Re: do_IRQ: stack overflow: 872..
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 18 Jan 2005 13:57:35 -0800
Cc: shemminger@xxxxxxxx, dwmw2@xxxxxxxxxxxxx, ak@xxxxxxx, snort2004@xxxxxxx, bridge@xxxxxxxx, netdev@xxxxxxxxxxx, rusty@xxxxxxxxxxxxxxx
In-reply-to: <1105133241.3375.16.camel@xxxxxxxxxxxxxxxxxxxxx>
References: <1131604877.20041218092730@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <p73zn0ccaee.fsf@xxxxxxxxxxxxx> <1105117559.11753.34.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20050107100017.454ddadc@xxxxxxxxxxxxxxxxx> <1105133241.3375.16.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Fri, 07 Jan 2005 22:27:21 +0100
Bart De Schuymer <bdschuym@xxxxxxxxxx> wrote:

> How about something like the patch below (untested but compiles)?
> The current netfilter scheme adds one function call to the call chain
> for each NF_HOOK and NF_HOOK_THRESH. This can be prevented by executing
> the okfn in the calling function instead of in nf_hook_slow().
> I didn't check if there's any code that actually uses the return value
> from NF_HOOK. If so, this patch won't work well in its current form as -
> EPERM is now also returned for NF_QUEUE and NF_STOLEN.
> Another 2 calls of okfn can be postponed in br_netfilter.c by adding
> NF_STOP, which would work like NF_STOLEN except that okfn is still
> called. But I'd first like to get the IPv4/IPv6 fix for br_netfilter.c
> accepted (see another thread on netdev).

I believe I put in your ipv4/ipv6 br_netfilter fix already.

This NF_HOOK() change looks interesting.  Could we also do something like
running the deeper ->hard_start_xmit() via a triggered tasklet or something

<Prev in Thread] Current Thread [Next in Thread>