From owner-freebsd-net@FreeBSD.ORG Thu Nov 2 09:45:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14DE616A47B for ; Thu, 2 Nov 2006 09:45:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F60943D5F for ; Thu, 2 Nov 2006 09:45:13 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.180.200] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GfZ8I3l72-0004gS; Thu, 02 Nov 2006 10:45:11 +0100 From: Max Laier Organization: FreeBSD To: ??? Date: Thu, 2 Nov 2006 10:45:04 +0100 User-Agent: KMail/1.9.4 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. Content-Type: multipart/signed; boundary="nextPart3424761.XVr6h7v6Ly"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 09:45:14 -0000 --nextPart3424761.XVr6h7v6Ly Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 November 2006 09:26, . wrote: > Hi, > > I am confused by the use of inet_ntoa function in the kernel. > > The function inet_ntoa in the /sys/libkern/inet_ntoa.c uses a static > array static char buf[4 * sizeof "123"]; > to store the result. And it returns the address of the array to the > caller. > > I think this inet_ntoa is not reentrant, though there are several > functions calling it. If two functions call it simultaneously, the > result will be corrupted. Though I haven't really encountered this > situation, it may occur someday, especially when using > multi-processors. > > There is another reentrant version of inet_ntoa called inet_ntoa_r in > the same file. It has been there for several years, but just used by > ipfw2 for about four times in 7-CURRENT. In my patch, I replaced all > the calls to inet_ntoa with calls to inet_ntoa_r. > > By the way, some of the original calls is written in this style: > strcpy(buf, inet_ntoa(ip)) > The modified code is written in this style > inet_ntoa_r(ip, buf) > This change avoids a call to strcpy, and can save a little time. > > Here is the patch. > http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-n >et > > I've already sent to PR(kern/104738), but got no reply, maybe it should > be discussed here first? In general, correct IPs in logs and debugging messages are a good thing. =20 I'm not sure, however, it is a good thing to put 17 bytes of buffer space=20 on every function stack that might want to print an IP address. I think=20 it's less intrusive and equally good to have a hand full of static=20 buffers available which are given out in a round-robin fashion - as=20 attempted in ip6_sprintf. Obviously the buffer rotation needs to be=20 atomic, though. If a caller needs the result for more than logging - or=20 cares strongly - it can still allocate a private buffer and use the _r=20 version. A general replacement of all applications of inet_ntoa just=20 seems bloat. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3424761.XVr6h7v6Ly Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSb4lXyyEoT62BG0RAstnAJ9w/KjXzOkzXAzSvA55EyfBvDKRLgCfbvdq l3GZjdEUZFnCXLwde6n2FoE= =rSuh -----END PGP SIGNATURE----- --nextPart3424761.XVr6h7v6Ly--