Reentrant problem with inet_ntoa in the kernel

[MQ]

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
> 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?

By the way, implementing a printf/log which understands ipv4 address is
tedious,
perhaps.