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 PROTECTED]> 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 PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
