This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: network problem
- From: Andrew Lunn <andrew at lunn dot ch>
- To: John Mills <john dot m dot mills at alum dot mit dot edu>
- Cc: eCos Users <ecos-discuss at ecos dot sourceware dot org>, Rick Davis <rickdavisjr at comcast dot net>
- Date: Sat, 1 Sep 2007 12:38:39 +0200
- Subject: Re: [ECOS] network problem
- References: <004701c7e990$9e57b8e0$db072aa0$@net> <Pine.LNX.4.44.0708281248260.12499-100000@otter.localdomain>
Hi Folks
I've lost track of the different threads about memory leaks in the
network stack. It seems like one of the leaks being talked about here
was fixed a long time ago:
2003-07-28 Jay Foster <jay@systech.com>
* src/sys/kern/sockio.c:
Fixed memory leak in accept() call.
Do we still need locking in socreate()? socreate calls soalloc. That
has a comment /* XXX race condition for reentrant kernel */. The
actual problem is in zalloci which does not perform locking on the
linked list of elements in the pool.
We are re-entrant? socreate() is only called from bsd_socket().
bsd_socket() should only be called from socket(). socket() performs
locking, depending on what synchronisation protocol is in
use. bsd_tcpip has no synchronisation protocol, so two simultaneous
calls to socket() could result in a race!
Could somebody please submit a full patch for socreate.
Are there any other issues left?
Thanks
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss