forcedeth: napi schedule lock fix

This patch fixes a potential race condition between scheduling napi and completing napi poll. The call to netif_rx_schedule should be under protection of the lock (as is the completion), otherwise, interrupts could be masked off.

@@ -3407,10 +3407,10 @@
 
 #ifdef CONFIG_FORCEDETH_NAPI
 		if (events & NVREG_IRQ_RX_ALL) {
+			spin_lock(&np->lock);
 			netif_rx_schedule(dev, &np->napi);
 
 			/* Disable furthur receive irq's */
-			spin_lock(&np->lock);
 			np->irqmask &= ~NVREG_IRQ_RX_ALL;
 
 			if (np->msi_flags & NV_MSI_X_ENABLED)

@@ -3524,10 +3524,10 @@
 
 #ifdef CONFIG_FORCEDETH_NAPI
 		if (events & NVREG_IRQ_RX_ALL) {
+			spin_lock(&np->lock);
 			netif_rx_schedule(dev, &np->napi);
 
 			/* Disable furthur receive irq's */
-			spin_lock(&np->lock);
 			np->irqmask &= ~NVREG_IRQ_RX_ALL;
 
 			if (np->msi_flags & NV_MSI_X_ENABLED)

From: Ayaz Abdulla <[email protected]>
Date: Fri, 09 Jan 2009 16:03:49 -0500

Another patch I had to apply by hand.

The 'dev' argument was removed from the netif_*() NAPI interfaces and then were converted to napi_*() in the net-2.6 tree.

Can you explain how this issue or race can occur (interrupts can be masked off) ?

netif_rx_schedule() merely mark soft irq as waked on current CPU. So dev->poll will not be called until irq_exit() or local_bh_enable. As nv_nic_irq() is run under interrupt context, so napi poll will be called only during irq_exit.

Thank,
Vitaliy Gusev