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
