Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Nov 2006 08:25:43 -0600
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        "." <antinvidia@gmail.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Reentrant problem with inet_ntoa in the kernel
Message-ID:  <20061102142543.GC70915@lor.one-eyed-alien.net>
In-Reply-To: <be0088ce0611020026y4fe07749pd5a984f8744769b@mail.gmail.com>
References:  <be0088ce0611020026y4fe07749pd5a984f8744769b@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 02, 2006 at 08:26:27AM +0000, . wrote:
> Hi,
>=20
> I am confused by the use of inet_ntoa function in the kernel.
>=20
> 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 calle=
r.
>=20
> I think this inet_ntoa is not reentrant, though there are several functio=
ns
> calling it. If two functions call it simultaneously, the result will be
> corrupted. Though I haven't really encountered this situation, it may occ=
ur
> someday, especially when using multi-processors.
>=20
> 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.
>=20
> 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.
>=20
> Here is the patch.
> http://people.freebsd.org/~delphij/misc/patch-itoa-by-nodummy-at-yeah-net
>=20
> 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

--kfjH4zxOES6UT95V
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFSf/mXY6L6fI4GtQRAq3/AKCzT92xeif23vFSDc2k1b3ZpFdolACgx8n6
da2TOJtPJpXc2Q3N9Ih7Ju0=
=GyRC
-----END PGP SIGNATURE-----

--kfjH4zxOES6UT95V--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061102142543.GC70915>