From: Jan-Bernd Themann <ossthema@de.ibm.com>

Ok, for now I'm going to try and deal with this by reverting
the list handling to something approximating the old NAPI
code, as per the patch below.

I've only quickly test booted into this kernel on my workstation.
So take care when trying it out.

I took the liberty to add some assertions and comments all over
wrt. list and quota handling.  One thing to note that (and this
was true previously too) that if ->poll() uses the whole quota
it _MUST_ _NOT_ modify the NAPI state by doing a complete or
reschedule.  The net_rx_action code still owns the NAPI state in
that case, and therefore is allowed to make modifications to the
->poll_list.

I realize this adds a lot of IRQ enable/disable overhead back
into the code, but we can't get rid of that cleanly without
solving this list ownership and modification issue properly.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0106fa6..9837ed3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -284,7 +284,14 @@ extern int __init netdev_boot_setup(char *str);
  * Structure for NAPI scheduling similar to tasklet but with weighting
  */
 struct napi_struct {
+	/* The poll_list must only be managed by the entity which
+	 * changes the state of the NAPI_STATE_SCHED bit.  This means
+	 * whoever atomically sets that bit can add this napi_struct
+	 * to the per-cpu poll_list, and whoever clears that bit
+	 * can remove from the list right before clearing the bit.
+	 */
 	struct list_head	poll_list;
+
 	unsigned long		state;
 	int			weight;
 	int			quota;
@@ -336,13 +343,21 @@ static inline void napi_schedule(struct napi_struct *n)
  *
  * Mark NAPI processing as complete.
  */
-static inline void napi_complete(struct napi_struct *n)
+static inline void __napi_complete(struct napi_struct *n)
 {
 	BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
+	list_del(&n-&...
[ message continues ]

Hi,


I'm currently updating the eHEA polling function to work with this
scheme. Up to now we had sort of a quota for or TX refill part as well,
which was also done in the poll function. This was possible as the device
could be scheduled again even if the quota has not been used
completely. If I got it right this is not longer possible. 
The idea was to benefit from the same "fairness" scheme of NAPI as it is
done for the RX side.

One other thing I observed is that I can not unload the module as the
ref counter of the eth device is too low. I haven't tracked down the 
source of this problem yet.

Regards,
Jan-Bernd
-

> One other thing I observed is that I can not unload the module as the
 > ref counter of the eth device is too low. I haven't tracked down the 
 > source of this problem yet.

I suspect that this is because netif_rx_reschedule() was missing a
dev_hold() to match the dev_put() in netif_rx_complete().  Dave merged
a fix for that problem yesterday, so current net-2.6.24 should be OK.
Let us know if it's not OK, because then there's another bug...

 - R.
-

When I applied this netif_rx_reschedule fix this problem did not occur
anymore (module could be unloaded). So I guess I hit the problem you
described.

Thanks,
Jan-Bernd
-

From: Jan-Bernd Themann <ossthema@de.ibm.com>

This is probably because of the resched device refcounting
bug that Roland Dreier just posted a fix for.

Look for subject "Fix refcounting problem with netif_rx_reschedule()"

I merge that in shortly to net-2.6.24 as well.
-