kern/104738: [patch]Reentrant problem with inet_ntoa in the kernel

user from china nodummy at yeah.net
Tue Oct 24 00:10:24 PDT 2006


>Number:         104738
>Category:       kern
>Synopsis:       [patch]Reentrant problem with inet_ntoa in the kernel
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 24 07:10:18 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     user from china
>Release:        7-CURRENT & 6.1-RELEASE
>Organization:
none
>Environment:
>Description:
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 corruptted. Though I haven't really encountered this situation, it may occur someday, especially when using multi-processor.
>How-To-Repeat:

>Fix:
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 changed code looks like
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
>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list