From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9261 invoked by alias); 27 Jun 2013 13:43:35 -0000 Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org Received: (qmail 9251 invoked by uid 89); 27 Jun 2013 13:43:35 -0000 X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from dub0-omc1-s8.dub0.hotmail.com (HELO dub0-omc1-s8.dub0.hotmail.com) (157.55.0.207) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 27 Jun 2013 13:43:34 +0000 Received: from DUB124-W10 ([157.55.0.239]) by dub0-omc1-s8.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jun 2013 06:43:31 -0700 X-TMN: [1GlfrLwIm2Dgdovp51q1MHVJtZAC6NGx] Message-ID: From: Bernd Edlinger To: =?iso-8859-1?B?TGFtYnJlY2h0IEr8cmdlbg==?= , "ecos-devel@ecos.sourceware.org" Subject: RE: RFC: bsd_tcp patch on in.c Date: Thu, 27 Jun 2013 13:43:00 -0000 In-Reply-To: <51CC20E1.3090502@televic.com> References: <51CC20E1.3090502@televic.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00003.txt.bz2 Hi J=FCrgen, > The patch below we already use since 2006. > We had problems with the TCP/IP stack directly after booting because it > already received packets before being initialized completely. > Here our CVS log: > > move > splx(s); > from line 682 to line 739 > so that tcp/ip stack has started up before the ethernet driver is released > (else the not-ready stack will already receive packets) > > Do you agree this is a valid patch? that is hard to tell - probably it is not necessary to lock anything here, especially because the in_control() does many things with the=A0 in_ifaddrhead list, without any lock. It just locks when it adds/removes entries from that list, which is really the bare minimum. I had similar problems however: an ICMP packet arriving while there was zero interface addresses registered. =3D> NULL pointer access in sys/ne= tinet/ip_icmp.c see the hunk at ip_icmp.c, lines=A0651-656. This means that the packet may arrive well before in_ifinit is called. Even before line 293 of in.c enters= the address to the list: this place is locked with splnet however. That null pointer access became only apparent after I changed the MMU to ex= clude page zero, because usually the arm processor would silently allow read accesses to the= ISR table. See my patch at=A0 http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D100164= 9 for details on=A0 "MMU: added Access Protection against NULL-Pointer accesses". Before I had invented that patch it was really hard to find such hideous bu= gs. Regards Bernd Edlinger=20=09=09=20=09=20=20=20=09=09=20=20