lkml.org 
[lkml]   [2000]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.028 / U:0.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site