| To: | "chas williams - CONTRACTOR" <chas@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC] locking changes for lec.c |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Fri, 14 Jan 2005 13:56:12 -0800 |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <200501061717.j06HHJ5I000508@ginger.cmf.nrl.navy.mil> |
| References: | <200501061717.j06HHJ5I000508@ginger.cmf.nrl.navy.mil> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Thu, 06 Jan 2005 12:17:20 -0500 "chas williams - CONTRACTOR" <chas@xxxxxxxxxxxxxxxx> wrote: > after looking at things recently its not clear to me that the combination > of lec_arp_lock and lec_arp_users was protecting things properly. > here is a small rewrite that eliminates lec_arp_users completely and > uses lec_arp_lock to protect the lists in lec_prev: lec_arp_tables, > lec_arp_empty_ones, et al. 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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [DEBUG]: sk_forward_alloc assertion failures, Herbert Xu |
|---|---|
| Next by Date: | Re: is there any plan to support BSD accept filter?, Stephen Hemminger |
| Previous by Thread: | [RFC] locking changes for lec.c, chas williams - CONTRACTOR |
| Next by Thread: | Re: [RFC] locking changes for lec.c, chas williams - CONTRACTOR |
| Indexes: | [Date] [Thread] [Top] [All Lists] |