| To: | Matt Mackall <mpm@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: Followup to netpoll issues |
| From: | Francois Romieu <romieu@xxxxxxxxxxxxx> |
| Date: | Fri, 7 Jan 2005 23:41:55 +0100 |
| Cc: | Mark Broadbent <markb@xxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050107220723.GB2940@xxxxxxxxx> |
| References: | <1105045914.7687.3.camel@tigger> <20050106234610.GT2940@xxxxxxxxx> <20050107011547.GE27896@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20050107170118.GU2940@xxxxxxxxx> <20050107214254.GA17317@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20050107220723.GB2940@xxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.1i |
Matt Mackall <mpm@xxxxxxxxxxx> : [...] > > Sorry if I was not clear: "from anywhere" meant printk issued from > > any part of the kernel which can interrupt the xmit_locked section > > of a qdisc_run(), i.e. printk from irq handlers. > > Hrmm. Yes, that's uglier than I realized. > > Perhaps there's a way to use the existing IRQ handler reentrancy > avoidance to detect that we might be about to recurse on a lock. It would help if qdisc_restart() disabled irq until xmit_lock_owner is set (an extra memory barrier would be required btw). I'd say to go with in_irq() + try_lock() but one could object that try_lock() leaves a window where a late thread could steal the lock. -- Ueimor |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: V2.4 policy router operates faster/better than V2.6, Jesse Brandeburg |
|---|---|
| Next by Date: | Re: V2.4 policy router operates faster/better than V2.6, Jeremy M. Guthrie |
| Previous by Thread: | Re: Followup to netpoll issues, Matt Mackall |
| Next by Thread: | Re: Followup to netpoll issues, Mark Broadbent |
| Indexes: | [Date] [Thread] [Top] [All Lists] |