Re: do_IRQ: stack overflow: 872..

[David Woodhouse <dwmw2@infradead.org>]

On Fri, 2005-01-07 at 10:00 -0800, Stephen Hemminger wrote:
> > 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.

The NFS case didn't involve hardware interrupts. Except for the one
which actually detected that the stack had overflowed.

> 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).

That's also a possibility.

> > 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.

Yeah, I suppose I'm inclined to agree.

-- 
dwmw2