On Mon, Feb 16, 2015 at 7:00 PM, Matthew Hall <mhall at mhcomputing.net> wrote:
> On Mon, Feb 16, 2015 at 10:33:52AM -0600, Jay Rolette wrote: > > In kni_net_rx_normal(), it was calling netif_receive_skb() instead of > > netif_rx(). The source for netif_receive_skb() point out that it should > > only be called from soft-irq context, which isn't the case for KNI. > > For the uninitiated among us, what was the practical effect of the coding > error? Waiting forever for a lock which will never be available in IRQ > context, or causing unintended re-entrancy, or what? > Sadly, I'm not really one of the enlightened ones when it comes to the Linux kernel. VxWorks? sure. Linux kernel? learning as required. I didn't chase it down to the specific mechanism in this case. Unusual for me, but this time I took the expedient route of finding a likely explanation plus Yao's fix on that same code with his explanation of a deadlock and went with it. It'll be a few more days before we've had enough run time on it to absolutely confirm (not an easy bug to repro). If I get hand-wavy about it, my assumption is that the requirement for netif_receive_skb() be called in soft-irq context means it doesn't expect to be pre-empted or rentrant. When you call netif_rx() instead, it puts the skb on the backlog and it gets processed from there. Part of that code disables interrupts during part of the processing. Not sure what else is coming in and actually deadlocking things. Honestly, I don't understand enough details of how everything works in the Linux network stack yet. I've done tons of work on the network path of stack-less systems, a bit of work in device drivers, but have only touched the surface of the internals of Linux network stack. The meat of my product avoids that like the plague because it is too slow. Sorry, lots of words but not much light being shed this time... Jay
