Messages in this thread |  | | From | "Petr Vandrovec" <> | Date | Fri, 29 Sep 2000 11:55:29 MET-1 | Subject | Re: OOPS on booting 2.4.0-test9pre7 during Novell server mo |
| |
On 29 Sep 00 at 1:51, Jeff V. Merkey wrote: > Describein more detail, perhaps I can help.
Hi Jeff, this is what I send just half a hour ago to Linux-net as response to someone else's request... I can't think any reason why info@primakow.ru got that oops except if one part of kernel was compiled with different options that another, and so ipx specific info was overwritten by generic socket layer... If recompiling whole kernel+modules does not fix it, then also bit error in lowest order bit can cause it (remember, sk->protinfo.af_ipx.intrfc was (void*)1). Best regards, Petr Vandrovec vandrove@vc.cvut.cz
From: Self <VCNET/VANDROVE> To: Yuri Syrota <yuri@renome.rovno.ua> Subject: Re: spx socket Cc: linux-net@vger.kernel.org Date: Fri, 29 Sep 2000 11:15:56 MET-1
On 29 Sep 00 at 9:53, Yuri Syrota wrote: > > will be fixed spx sockets in kernel 2.4?
I do not think. But maybe I'm wrong. Jeff Merkey from Timpanogas was talking about this and SPXII implementation some time ago, but I believe that after he saw sources, he forgot about fixing, and is now investigating possibility of complete reimplementation (as for SPXII client port number can change after connection is opened, only SPX connection ID is thing which matters, not (port,connID) pair... dunno why spec says this).
And if someone has interest in fixing SPX... Please, look into IPX first. My understanding is that
ipx_rcv -> ipxitf_auto_create -> ipxitf_insert
contains no locking against concurrent ipxitf_create -> ipxitf_insert, ipxitf_delete -> ipxitf_down, and, worse,
ipx_rcv -> ipxitf_find_using_phys
accesses ipx_interfaces linked list without any lock, so it can run in parallel with ioctl->ipxitf_delete->ipxitf_down...
Or does ipx_rcv run under big kernel lock? I do not think ;-) Same races occurs in routing code wrt ipx routing table... Also linked list, also no locks. Even worse, ipxrtr_add_route first insert kmalloced route entry into list, and fills it with valid data after that! So you can retrieve invalid rt->ir_intrfc, causing oops...
If you do not use 'ipx_configure --auto_interface=on --auto_primary=on' and you disconnect network cable when doing manipulations with routing table (running 'ipx_route' and/or 'nwsfind' and/or 'ipxd'), you are on safe side... Having one CPU makes race windows smaller, but does not close them (f.e. received packet while in the middle of ipxrtr_add_route...) Best regards, Petr Vandrovec vandrove@vc.cvut.cz
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |