Subject: Re: [PATCH 1/2] e1000: fix netpoll with NAPI

From: Neil Horman <[email-masked]>
Date: Sun, 11 Jun 2006 20:13:56 -0400

On Thu, Jun 08, 2006 at 01:29:00PM -0400, Jeff Moyer wrote:
> ==> Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Mitch Williams <[email-masked]> adds:
> 
> mitch.a.williams> On Wed, 2006-06-07 at 11:44 -0700, Jeff Moyer wrote:
> >> That patch locks around the tx clean routine.  As such, it doesn't
> >> prevent the problem.
> 
> mitch.a.williams> The call to netif_rx_schedule_prep provides locking
> mitch.a.williams> because it sets the __LINK_STATE_RX_SCHED bit atomically.
> mitch.a.williams> The spinlock around e1000_clean_tx_irq is to protect it
> mitch.a.williams> from other calls to the transmit routine, not NAPI.
> 
> Yes, but what prevents recursion in the poll routine?  Consider that the
> poll routine could end up triggerring a printk (think iptables, here).  In
> that case, you end up calling into netpoll, and if the tx ring is full, we
> call the poll_controller routine.  We've now recursed.
> 
> The poll lock was originally introduced to prevent recursion, not
> concurrent access.
> 
Any further thoughts on this guys?  I still think my last solution solves all of
the netpoll problems, and isn't going to have any noticable impact on
performance.

Regards
Neil

> -Jeff
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email-masked]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html