Reentrant problem with inet_ntoa in the kernel
antinvidia at gmail.com
Fri Nov 3 09:46:50 UTC 2006
2006/11/2, Brooks Davis <brooks at 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
> > static char buf[4 * sizeof "123"];
> > to store the result. And it returns the address of the array to the
> > I think this inet_ntoa is not reentrant, though there are several
> > calling it. If two functions call it simultaneously, the result will be
> > corrupted. Though I haven't really encountered this situation, it may
> > someday, especially when using multi-processors.
> > There is another reentrant version of inet_ntoa called inet_ntoa_r in
> > same file. It has been there for several years, but just used by ipfw2
> > 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.
> > I've already sent to PR(kern/104738), but got no reply, maybe it should
> > 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?
By the way, implementing a printf/log which understands ipv4 address is
More information about the freebsd-net