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 [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
From: Self <VCNET/VANDROVE>
To: Yuri Syrota <[EMAIL PROTECTED]>
Subject: Re: spx socket
Cc: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
