On Tue, Sep 06, 2005 at 06:37:40PM -0700, Eugene Surovegin wrote: > On Tue, Sep 06, 2005 at 06:03:38PM -0700, Matt Mackall wrote: > > On Tue, Sep 06, 2005 at 04:01:24PM -0700, David S. Miller wrote: > > > So you cannot call into these drivers with HW interrupts disabled or > > > even worse from HW interrupt context. These drivers use locking > > > strategies which are perfectly legal and work until you add netpoll. > > > > And again, I agree. > > > > What I disagree with is the claim that it's netpoll that's "broken". > > Again, I claim that netpoll is not doing something fundamentally > > unreasonable. Driving hardware by polling with interrupts disabled is > > nothing magic, it's just something the network stack to date has not > > been designed to cope with. > > Well, it's not driving hw in polling mode with hw IRQs disabled > (in fact, NAPI does exactly this), it's _calling_ driver entry > points from illegal context. IMHO this is not the same.
The only reasonable way for core code to manipulate hardware is calling driver interfaces, so I think you're splitting hairs. > > So we can either: > > > > a) have a netpoll that's crippled to softirq-only > > b) live with some amount of localized brain damage here > > c) attempt to make the stack more netpoll-accomodating > > or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) > > In this case, even if driver cannot handle being called from IRQ > context, netconsole still can be used, although in a little more > limited fashion, but being safe and not causing lock ups, which, as > far as I understand you, it was designed to help debugging in the > first place :). Again, there's basically no point to this at all. It won't catch an appreciable number of diagnostics that are not already caught by syslog and it won't work with kgdb-over-ethernet, netdump, etc. -- 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
