Re: do_IRQ: stack overflow: 872..

[Stephen Hemminger <shemminger@osdl.org>]

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

On Fri, 07 Jan 2005 17:05:59 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> On Sat, 2004-12-18 at 08:50 +0100, Andi Kleen wrote:
> > It's not really an oops, just a warning that stack space got quiet
> > tight.
> > 
> > The problem seems to be that the br netfilter code is nesting far too
> > deeply and recursing several times. Looks like a design bug to me,
> > it shouldn't do that.
> 
> I don't think it's recursing -- I think the stack trace is just a bit
> noisy. The problem is that the bridge code, especially with br_netfilter
> in the equation, is implicated in code paths which are just _too_ deep.
> This happens when you're bridging packets received in an interrupt while
> you were deep in journalling code, and it's also been seen with a call
> trace something like nfs->sunrpc->ip->bridge->br_netfilter.

Sounds like an argument for interrupt stacks.

> One option might be to make br_dev_xmit() just queue the packet rather
> than trying to deliver it to all the slave devices immediately. Then the
> actual retransmission can be handled from a context where we're _not_
> short of stack; perhaps from a dedicated kernel thread. 

Probably the solution would be to handle it in the filter code
that way if we are not filtering, we can use the interrupt path,
but if filtering just defer to a safer context (like soft irq).

> Unfortunately that approach would introduce a lot of latency on all
> packets we pass. Another option would be to have all architectures
> provide a stack_available() function and for br_dev_xmit() to queue the
> packet only if we're short of stack, while still sending most packets
> immediately. 

NO, that looks like a testablity and portablity nightmare.

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Bridge mailing list
Bridge@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/bridge