| To: | chas3@xxxxxxxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: [RFC] locking changes for lec.c |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Fri, 14 Jan 2005 20:33:51 -0800 |
| Cc: | chas@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <200501150232.j0F2Wovr010942@xxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <20050114135612.0edc180d.davem@xxxxxxxxxxxxx> <200501150232.j0F2Wovr010942@xxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Fri, 14 Jan 2005 21:32:51 -0500 "chas williams - CONTRACTOR" <chas@xxxxxxxxxxxxxxxx> wrote: > In message <20050114135612.0edc180d.davem@xxxxxxxxxxxxx>,"David S. Miller" > writes: > >Can HW interrupt paths ever call into this ARP stuff? > >If not, probably should just use BH disabled locking > >instead of the heavy handed IRQ disabling locks. > > yes, lec_push() could be run in hw interrupt context from one of of the > atm drivers recv path. in fact, this is the path where i "noticed" the > race condition. Ok. As a future thought, if you make the ATM driver receive path NAPI in style or run always from softint processing, you can undo all the IRQ based locking. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: "Badness" again, Jeff Garzik |
|---|---|
| Next by Date: | [PATCH] merge sctp_opt with sctp_sock, Arnaldo Carvalho de Melo |
| Previous by Thread: | Re: [RFC] locking changes for lec.c, chas williams - CONTRACTOR |
| Next by Thread: | Fw: [Bug 3998] New: ARP issues after 2.4.28-RC1, Stephen Hemminger |
| Indexes: | [Date] [Thread] [Top] [All Lists] |