| To: | Matt Mackall <mpm@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] Prevent netpoll hanging when link is down |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Fri, 8 Oct 2004 01:50:22 +0200 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, ak@xxxxxxx, colin@xxxxxxxxxx, akpm@xxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <20041007234322.GW31237@xxxxxxxxx> |
| References: | <20041006214322.GG31237@xxxxxxxxx> <20041007075319.6b31430d@xxxxxxxxxxxxxxx> <20041006234912.66bfbdcc.davem@xxxxxxxxxxxxx> <20041007160532.60c3f26b@pirandello> <20041007112846.5c85b2d9.davem@xxxxxxxxxxxxx> <20041007224422.1c1bea95@xxxxxxxxxxxxxxx> <20041007214505.GB31558@xxxxxxxxxxxxx> <20041007215025.GT31237@xxxxxxxxx> <20041007150756.2373719f.davem@xxxxxxxxxxxxx> <20041007234322.GW31237@xxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
> Deadlocks from recursion, presumably? We could probably throw in a max > retry count, as ugly as that is.. There should not be any recursion, no. The problem is that the poll is effectively a spinlock. But when another CPU takes an long interrupt while holding the lock it could take quite a long time to grab the lock. For most network drivers this shouldn't occur though because the net driver private lock is usually always taken with interrupts off. -Andi |
| Previous by Date: | Re: 2.6.7 tulip performance (with NAPI), Lennert Buytenhek |
|---|---|
| Next by Date: | PATCH 1/1: [SKBUFF] move common code to hdlc_type_trans, Arnaldo Carvalho de Melo |
| Previous by Thread: | Re: [PATCH] Prevent netpoll hanging when link is down, Matt Mackall |
| Next by Thread: | Re: [PATCH] Prevent netpoll hanging when link is down, Colin Leroy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |