On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote: > Looking at the netpoll routines, I noticed that the find_skb could > lockup if the memory is low. This is because the allocations are > called with GFP_ATOMIC (since this is in interrupt context) and if > it fails, it will continue to fail. This is just by observing the > code, I didn't have this actually happen. So if this is not the > case, please let me know how it can get out. Otherwise, please > accept this patch.
By netpoll_poll() tickling the driver enough to free the currently queued outgoing SKBs. Also note that by the time we're in this loop, we're ready to take desperate measures. We've already exhausted our private queue of SKBs so we have no alternative but to keep kicking the driver until something happens. The netpoll philosophy is to assume that its traffic is an absolute priority - it is better to potentially hang trying to deliver a panic message than to give up and crash silently. > Also, as Andi told me, the printk here would probably not show up > anyway if this happens with netconsole. That's fine. But in fact, it does show up occassionally - I've seen it. NAK'ed. -- Mathematics is the supreme nostalgia of our time. - 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