From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 11:21:02 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 B32CF16A40F for ; Fri, 3 Nov 2006 11:21:02 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B22443D4C for ; Fri, 3 Nov 2006 11:21:01 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.55] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gfx6V1Unc-0007Yv; Fri, 03 Nov 2006 12:20:56 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 3 Nov 2006 12:20:47 +0100 User-Agent: KMail/1.9.4 References: <20061102142543.GC70915@lor.one-eyed-alien.net> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13722607.rEsWsyqbVX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611031220.53791.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: MQ 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: Fri, 03 Nov 2006 11:21:02 -0000 --nextPart13722607.rEsWsyqbVX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello "MQ", your email client is seriously mis-configured, could you please look into=20 this as it is a bit annoying. On Friday 03 November 2006 10:46, MQ wrote: > 2006/11/2, Brooks Davis : > > On Thu, Nov 02, 2006 at 08:26:27AM +0000, . 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 > >-net > > > > > I've already sent to PR(kern/104738), but got no reply, maybe it > > > should > > > > be > > > > > discussed here first? > > > > I've got to agree with other posters that the stack variable > > allocations are ugly. What about extending log and printf to > > understand ip4v addresses? That's 90% of the uses and the others > > appears to have buffers already. > > > > -- Brooks > > > > Ugly? Why? Don't you use local variables in your sources? You have to understand, that stack space is a limited resource in the=20 kernel. Some of the functions are leaf nodes in quite long call paths,=20 which means adding those buffers can hit quite hard. I guess what Brooks and I are trying to say is, that this needs to be=20 considered carefully. A simple search and replace won't do. BTW, I took the PR for now and will look into it. I don't think it's=20 something we need to rush, as I haven't seen any reports or indication of=20 real problems yet - fwiw we don't spew a lot of IP addresses to console=20 or log in normal operation. > By the way, implementing a printf/log which understands ipv4 address is > tedious, perhaps. Actually, it's a ~15 line patch, I will see if I can get to it later=20 today. If we reuse the number buffer we can even get away without=20 increase in stack space usage. Whether or not this is a good idea is on=20 another page, but %I and %lI (for IPv6) would be available and we already=20 have %D and %b as special cases in the kernel. =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 --nextPart13722607.rEsWsyqbVX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSyYVXyyEoT62BG0RAiK5AJ0ePyHawzNTWzi9ICYwfEi5+ljVQwCfcViP I5x2oUBUWdAeJIgoDioVXRw= =ic6M -----END PGP SIGNATURE----- --nextPart13722607.rEsWsyqbVX--