Date: Fri, 3 Nov 2006 08:17:32 -0600 From: Brooks Davis <brooks@one-eyed-alien.net> To: MQ <antinvidia@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel Message-ID: <20061103141732.GA87515@lor.one-eyed-alien.net> In-Reply-To: <be0088ce0611030146u5e97e08cmbd36e94d772c8a94@mail.gmail.com> References: <be0088ce0611020026y4fe07749pd5a984f8744769b@mail.gmail.com> <20061102142543.GC70915@lor.one-eyed-alien.net> <be0088ce0611030146u5e97e08cmbd36e94d772c8a94@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 03, 2006 at 09:46:47AM +0000, MQ wrote: > 2006/11/2, Brooks Davis <brooks@one-eyed-alien.net>: > > > >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? The particular definition used is excedingly ugly. At a minimum there needs to be a define or a constant "16" for the lenght rather than the 4*sizeof("123") nonsense. -- Brooks --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFS097XY6L6fI4GtQRAoOPAKDLTwMk9dwS7nfGbcRPXpcCRn8RSQCggTqp qV/yvysM1DeTsM2fHlCp3Vk= =Wwt0 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061103141732.GA87515>