Date: Tue, 24 Oct 2006 07:00:55 GMT From: user from china<nodummy@yeah.net> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/104738: [patch]Reentrant problem with inet_ntoa in the kernel Message-ID: <200610240700.k9O70tKD006039@www.freebsd.org> Resent-Message-ID: <200610240710.k9O7AIYZ045013@freefall.freebsd.org>
index | next in thread | raw e-mail
>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:help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610240700.k9O70tKD006039>