| To: | chas williams <chas@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1 |
| From: | Francois Romieu <romieu@xxxxxxxxxxxxx> |
| Date: | Thu, 5 Feb 2004 19:38:13 +0100 |
| Cc: | "Randy.Dunlap" <rddunlap@xxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <200402051222.i15CMcRr029937@xxxxxxxxxxxxxxxxxxxxxxx>; from chas@xxxxxxxxxxxxxxxx on Thu, Feb 05, 2004 at 07:22:40AM -0500 |
| References: | <romieu@xxxxxxxxxxxxx> <200402051222.i15CMcRr029937@xxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5.1i |
chas williams <chas@xxxxxxxxxxxxxxxx> : [...] > how about the following instead? we probably shouldnt register the As long as the ugly-ifdef patrol does not bite, it's fine with me. :o) > proc entry until clip_tbl is going to be ready for use anyway (the > arp table iterators should probably also use clip_tbl instead of > clip_tbl_hook). It would not hurt. Do you have a specific race in mind before I send an update on top your patch for the clip_tbl_hook -> clip_tbl change ? -- Ueimor |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Deadlock problem with dev->refcnt somewhere in netlink/multicast... [PATCH], Willy Tarreau |
|---|---|
| Next by Date: | Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1, contractor |
| Previous by Thread: | Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1, contractor |
| Next by Thread: | Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1, contractor |
| Indexes: | [Date] [Thread] [Top] [All Lists] |